From nobody Fri Apr 1 03:32:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF512D53C for ; Fri, 1 Apr 2016 03:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70G-ERSrvsjh for ; Fri, 1 Apr 2016 03:32:40 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 99E3E12D0B4 for ; Fri, 1 Apr 2016 03:32:40 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 182ECCA09C626 for ; Fri, 1 Apr 2016 10:32:38 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u31AWdKV004581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Apr 2016 10:32:39 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u31AWc39024644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Apr 2016 10:32:39 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.148]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 1 Apr 2016 06:32:39 -0400 From: "Carey, Timothy (Nokia - US)" To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-tcp-tls-01.pdf Thread-Index: AdGMAc8fXF7ashssRByCfwbBRtO6Ug== Date: Fri, 1 Apr 2016 10:32:37 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A61EDC4@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77012A61EDC4US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: [core] draft-ietf-core-coap-tcp-tls-01.pdf X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 10:32:45 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77012A61EDC4US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, In section 4 Message Format says: The 'Message Length' field is a 16-bit unsigned integer in network byte order. It provides the length of the subsequent CoAP message (including the CoAP header but excluding this message length field) in bytes (so its minimum value is 2). The Message ID and message type are meaningless and thus elided (what would have been the message type field is always filled with what would be the code for NON (01)). What would happen if an Application where to place a CON in the message typ= e field. Based on my reading of this text I would expect the message type f= rom the application to be ignored and the transport to put in a NON messag= e. Is that correct? BR, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77012A61EDC4US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

In section 4 Message Format says:

The ’Message Len= gth’ field is a 16-bit unsigned integer in network

byte order. It provide= s the length of the subsequent CoAP message

(including the CoAP he= ader but excluding this message length field)

in bytes (so its minim= um value is 2). The Message ID and message

type are meaningless a= nd thus elided (what would have been the

message type field is = always filled with what would be the code for

NON (01)).

 

What would happen if an Application where to place a= CON in the message type field. Based on my reading of this text I would ex= pect the message type from the  application to be ignored and the tran= sport to put in a NON message. Is that correct?

 

BR,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77012A61EDC4US70UWXCHMBA0_-- From nobody Fri Apr 1 07:04:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787F912D5EF for ; Fri, 1 Apr 2016 07:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiRHE84QoxW0 for ; Fri, 1 Apr 2016 07:04:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC5512D59D for ; Fri, 1 Apr 2016 07:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eZuqAhoPNOB0NZckojhF/jgFBJGPMDctjH6SvEp7E7s=; b=xBteevq+cJNWKp8gMFxOzlIqLBlj4FZ8e+wxgLQpzpMKt25SN5bwjD2PXdTSNV5/teJP0IVJpsrtu0IIBkzyt739W62H/2MCd/1RHJz/f+OQeksbJcdVKyh6ADZ3g7oq82RxYv+uLLRcYrSVoYxtxHF4173Rpa5fBNFYMeTwJbA= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 1 Apr 2016 14:03:50 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0447.026; Fri, 1 Apr 2016 14:03:50 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] COOL SID representation Thread-Index: AQHRioLe9YC4kcsTek+wcq535Vsfz591H9Dg Date: Fri, 1 Apr 2016 14:03:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: e60fa9c7-c565-4bd8-c434-08d35a367382 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:F44kXofWWFZPsh30UD8vtbnw7I4Z4NmxMok3kZJixq3AAryvY9nxrep2YNMlAgYneR03mR0QehfNxpmr5yb2is4N4kN/Foxm+AjQDM7aP4YxLTDW915JlbvSpDnBqc6KkBk37LnUPURKKGHlgSYFig==; 24:NLVNt3tm1g0pBHB/kfJO18Shec2O9Fy+ISGId7XvcAlCR9glqCVV2jEzhISQnJI9ElNkvpXNP3gyxn+UiHDl9XmdBWr6ieWrnYu0XDfa+gA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0899B47777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(11100500001)(107886002)(15975445007)(92566002)(87936001)(10400500002)(122556002)(5001770100001)(106116001)(19580405001)(19580395003)(189998001)(3280700002)(99286002)(5008740100001)(2950100001)(76576001)(77096005)(66066001)(2906002)(2501003)(2900100001)(74316001)(5003600100002)(3660700001)(5004730100002)(586003)(81166005)(102836003)(6116002)(3846002)(86362001)(50986999)(5002640100001)(33656002)(1220700001)(15395725005)(54356999)(1096002)(76176999)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2016 14:03:49.8305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:04:14 -0000 Hi Peter I like your suggestion to show delta SIDs in the CBOR diagnostic notation u= sing the "+" sign. This syntax is supported by the CBOR diagnostic notation and tools like htt= p://cbor.me/ I did the modification in our working document, see: https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-= latest.html#container https://core-wg.github.io/yang-cbor/draft-veillette-core-yang-cbor-mapping-= latest.html#list For example: { 1708 : { # clock +2 : "2015-10-02T14:47:24Z-05:00", # current-datetime, SID 1710 +1 : "2015-09-15T09:12:58Z-05:00" # boot-datetime, SID 1709 } } About PUT and PATCH methods in CoOL, it's important to understand that the = payload contain a list of data nodes encoded using a CBOR array. This list implements previous sibling delta SID (instead of the parent delt= a SID implemented in containers and list instances). This list is defined in the intro of section 5.3 and 5.4: (https://core-wg.github.io/yang-cbor/draft-veillette-core-cool-latest.html#= put-updating-all-data-nodes-of-a-datastore) The payload of the PUT request MUST carry a CBOR array containing the ne= w content of the datastore. The CBOR array MUST contain a list of pairs of delta and associated valu= e. A delta represents the different between the current SID and the SID of the previous pair withi= n the CBOR array. Each value is encoded using the rules defined by [I-D.veillette-core-yang-cbo= r-mapping]. About the example you are referencing, the +15 is a previous sibling delta = SID within the CBOR array. (Top level list of data node) The value +3 for example is a parent delta SID within the CBOR map (YANG co= ntainer) I understand that this encoding is confusing for peoples but not very compl= ex for a computer. The alternate methods proposed to be as concise (such the Order Preserved M= ulti-Maps - OPMM) was a lot more complex.=20 https://core-wg.github.io/yang-cbor/draft-veillette-core-cool-latest.html#p= ut-updating-all-data-nodes-of-a-datastore PUT /c/r Content-Format(application/cool+cbor) [ 1727, 540, # timezone-utc-offset (SID 1727) +15, true, # enabled (SID 1742) +1, [ # server (SID 1743) { +3 : "tic.nrc.ca", # name (SID 1746) +4 : true, # prefer (SID 1747) +5 : { # udp (SID 1748) +6 : "132.246.11.231", # address (SID 1749) +7 : 123 # port (SID 1750) } }, { +3 : "tac.nrc.ca", # name (SID 1746) +4 : false, # prefer (SID 1747) +5 : { # udp (SID 1748) +6 : "132.246.11.232" # address (SID 1749) } } ]=20 ] Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: March-30-16 8:40 AM To: Core Subject: [core] COOL SID representation Hi Michel et al, I find the current representation of the SID rather confusing, both within = the examples as the CBOR encoding. The numeric values serving as YANG identifier are represented as difference= s with respect to a hierarchical higher value. It would be more clear if the operator aspect was shown in the examples:=20 e.g. +15 instead of 15. It is not clear to me why the operation is with respect to the parent sch= ema node. Could it not just be the former identifier? Efficiency considerations may t= hen indicate a reordering of the nodes, but that is not prohibitive for the= handling of the contents. From the above you may understand that I do not like misusing the "integer= " type in CBOR to annotate Delta's. It makes the interpretation of the CBOR types application dependent, and I = don't think that is a good direction to go. My recommendation is to develop a new CBOR element to denote the deltas. Greetings, Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Sat Apr 2 10:00:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7A12D125 for ; Sat, 2 Apr 2016 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKkseijYCFdF for ; Sat, 2 Apr 2016 10:00:46 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD5012D0D8 for ; Sat, 2 Apr 2016 10:00:45 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.216]) by smtp-cloud2.xs4all.net with ESMTP id dV0e1s00M4fjQrE01V0eW8; Sat, 02 Apr 2016 19:00:42 +0200 Received: from static.165.246.111.190.cps.com.ar ([190.111.246.165]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 02 Apr 2016 19:00:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 02 Apr 2016 19:00:38 +0200 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <9d745d97bcd403f17b090a78220c1c96@xs4all.nl> X-Sender: stokcons@xs4all.nl (Vck6wEfbS0QTY6pgzCFuJPF/lqYEiomH) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 17:00:48 -0000 Michel Veillette schreef op 2016-04-01 16:03: > Hi Peter > > I like your suggestion to show delta SIDs in the CBOR diagnostic > notation using the "+" sign. Fine it helps me at least. It would help as well if the annotation (may be not the CBOR contents) displays the parent value. > The payload of the PUT request MUST carry a CBOR array containing > the new content of the datastore. > The CBOR array MUST contain a list of pairs of delta and associated > value. A delta represents the > different between the current SID and the SID of the previous pair > within the CBOR array. Each > value is encoded using the rules defined by > [I-D.veillette-core-yang-cbor-mapping]. > This confuses me, because the ordering is used (e.g A delta represents the different between the current SID and the SID of the previous pair within the CBOR array); So why in arrays yes to ordering, and elsewhere, no to ordering. Especially as the client and server are both aware of the ordering in the payload; and the ordering will not change during transport. So on one hand you have the SIDs of the items to transport. On the other hand you transport them, and then you can encode them as you wish, also using the ordering as long as the generated SID values are correct. Peter From nobody Sat Apr 2 10:17:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD2A12D0D8 for ; Sat, 2 Apr 2016 10:17:18 -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] 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 nGnbpJPcZxJb for ; Sat, 2 Apr 2016 10:17:16 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998DD12D0B8 for ; Sat, 2 Apr 2016 10:17:16 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:1194:620c:985f:7131]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 87C48A80C4; Sat, 2 Apr 2016 19:17:10 +0200 (CEST) Message-ID: <56FFFE9C.70406@tzi.org> Date: Sat, 02 Apr 2016 14:17:16 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michel Veillette References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 17:17:18 -0000 Michel Veillette wrote: > I like your suggestion to show delta SIDs in the CBOR diagnostic notation using the "+" sign. > This syntax is supported by the CBOR diagnostic notation and tools like http://cbor.me/ (Actually, strictly speaking, this is a bug in cbor.me: +1 is not allowed in JSON, and the CBOR diagnostic notation as defined in section 6 of RFC 7049 does not explicitly extend JSON here. But I think we can just add the + sign to the number extensions defined for the extended diagnostic notation in appendix G.4 of draft-greevenbosch-appsawg-cbor-cddl, which is the one we want to use here.) Grüße, Carsten From nobody Sat Apr 2 12:52:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66912D128 for ; Sat, 2 Apr 2016 12:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpIYwMBYIfT8 for ; Sat, 2 Apr 2016 12:52:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9971712D140 for ; Sat, 2 Apr 2016 12:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9jja/x8aotvr71s4y9KdlCIu3IgooQGy8N8ueq4NdYE=; b=aRTKzsQ4l87mKjPXBXQvW6DVB48tL7saqDUsE13b4M8CoPoSp7sPn+kosVGjo9huJ8uyO2AcJKx6/I/rWDJv3/dBnbsFUePH/DCguirkSH3/8SV+CjqlNc/ortSSeg7A7JepCEcjH1l0QfBeJIEeQizbSa7mVuQKvcEg57Um50M= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sat, 2 Apr 2016 19:52:07 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0447.027; Sat, 2 Apr 2016 19:52:07 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] COOL SID representation Thread-Index: AQHRioLe9YC4kcsTek+wcq535Vsfz591H9DggAHNhgCAAC1TAA== Date: Sat, 2 Apr 2016 19:52:07 +0000 Message-ID: References: <9d745d97bcd403f17b090a78220c1c96@xs4all.nl> In-Reply-To: <9d745d97bcd403f17b090a78220c1c96@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [192.252.136.159] x-ms-office365-filtering-correlation-id: 004d3427-60bb-4110-0766-08d35b3045a4 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:oR61wwc93auU7JwxlJZhPU/BbTjD34uipuU7g7aRgsQ9jmnEhqdaIKWVnDxLl0OaAyJOMK1zmzVAeOl0OjNk8BTFlb/ll2koC3uoVKiiiKBJ9BnxB7pPNzbs/ZqbTijeT+hOipZlfhj2Ercaq+6NgQ==; 24:bQ9MU6u4j4FDf1PZzPdiRwEIEEeXkznWes+rISt5kfFYb1RKT5IljpKa1LV99JvXba9dFj8CEcx2w5uiDXcpZQc7ljzkXmhBz9qHlbBZh+Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 09007040D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(13464003)(1220700001)(1096002)(106116001)(2906002)(4326007)(99286002)(5008740100001)(33656002)(5004730100002)(6116002)(102836003)(3846002)(74316001)(2351001)(586003)(5640700001)(87936001)(15395725005)(5002640100001)(81166005)(76576001)(1730700002)(110136002)(2501003)(11100500001)(3660700001)(77096005)(50986999)(76176999)(122556002)(189998001)(66066001)(54356999)(10400500002)(3280700002)(19580405001)(19580395003)(86362001)(2900100001)(92566002)(5003600100002)(15975445007)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2016 19:52:07.2105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 Archived-At: Cc: Core Subject: Re: [core] COOL SID representation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 19:52:10 -0000 Hi Peter The constrains imposed by the CBOR map (ordering not preserved, no duplicat= e keys allowed) is not an issue during the transport, is something imposed = by the libraries used on both side (to serialize and de-serialise). For example, if you enter the following in http://cbor.me/ { 2 : "a", 2 : "b" } It will produce a cbor map with a single entry instead of two. a1 # map(1) 02 # unsigned(2) 61 # text(1) 62 # "b" http://cbor.me/ preserve the ordering but other libraries written in python= for example won't. Hope this answer your question. Michel -----Original Message----- From: peter van der Stok [mailto:stokcons@xs4all.nl]=20 Sent: April-02-16 1:01 PM To: Michel Veillette Cc: consultancy@vanderstok.org; Core Subject: RE: [core] COOL SID representation Michel Veillette schreef op 2016-04-01 16:03: > Hi Peter >=20 > I like your suggestion to show delta SIDs in the CBOR diagnostic=20 > notation using the "+" sign. Fine it helps me at least. It would help as well if the annotation (may be not the CBOR contents) disp= lays the parent value. > The payload of the PUT request MUST carry a CBOR array containing=20 > the new content of the datastore. > The CBOR array MUST contain a list of pairs of delta and associated=20 > value. A delta represents the > different between the current SID and the SID of the previous pair=20 > within the CBOR array. Each > value is encoded using the rules defined by=20 > [I-D.veillette-core-yang-cbor-mapping]. >=20 This confuses me, because the ordering is used (e.g A delta represents the = different between the current SID and the SID of the previous pair within t= he CBOR array); So why in arrays yes to ordering, and elsewhere, no to orde= ring. Especially as the client and server are both aware of the ordering in the p= ayload; and the ordering will not change during transport. So on one hand you have the SIDs of the items to transport. On the other hand you transport them, and then you can encode them as you w= ish, also using the ordering as long as the generated SID values are correc= t. Peter From nobody Sat Apr 2 15:36:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC312D130 for ; Sat, 2 Apr 2016 15:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wig62wyR7yFa for ; Sat, 2 Apr 2016 15:36:46 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF8A12D113 for ; Sat, 2 Apr 2016 15:36:45 -0700 (PDT) Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0CF8AFB881; Sun, 3 Apr 2016 00:36:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Xw2IrA9FlpEc; Sun, 3 Apr 2016 00:36:42 +0200 (CEST) X-Originating-IP: 31.133.163.55 Received: from dhcp-a337.meeting.ietf.org (dhcp-a337.meeting.ietf.org [31.133.163.55]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 7D890FB882; Sun, 3 Apr 2016 00:36:40 +0200 (CEST) Message-ID: <57004973.3060903@tzi.org> Date: Sat, 02 Apr 2016 19:36:35 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Agenda for IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 22:36:48 -0000 The agenda that is on the github wiki now also is at the official place: https://www.ietf.org/proceedings/95/agenda/agenda-95-core Presenters/discussion leaders: Please check the slots; please submit slides by COB Sunday (or COB Wednesday if you cannot do this and your slot is on the Friday). Grüße, Carsten From nobody Sat Apr 2 17:35:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68E12D0DB for ; Sat, 2 Apr 2016 17:35:24 -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] 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 hF-7AmeRzyRr for ; Sat, 2 Apr 2016 17:35:23 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8234E12D09A for ; Sat, 2 Apr 2016 17:35:23 -0700 (PDT) Received: from hebrews (unknown [190.104.214.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id EA1B938EF1; Sat, 2 Apr 2016 17:35:21 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , References: <57004973.3060903@tzi.org> In-Reply-To: <57004973.3060903@tzi.org> Date: Sat, 2 Apr 2016 21:35:18 -0300 Message-ID: <000901d18d40$b50ebb80$1f2c3280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG4nC8TauvAKUIpkddfohWbYorDIJ+pSNTQ Content-Language: en-us Archived-At: Subject: Re: [core] Agenda for IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 00:35:25 -0000 Putting the security documents on Friday against CFRG is a good way of = ensuring that some of the security people are going to be absent. Me = among them. Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Saturday, April 02, 2016 7:37 PM > To: core@ietf.org WG > Subject: [core] Agenda for IETF95 >=20 > The agenda that is on the github wiki now also is at the official = place: >=20 > https://www.ietf.org/proceedings/95/agenda/agenda-95-core >=20 > Presenters/discussion leaders: Please check the slots; please submit = slides by > COB Sunday (or COB Wednesday if you cannot do this and your slot is on = the > Friday). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sun Apr 3 16:08:39 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897B012D124 for ; Sun, 3 Apr 2016 16:08:38 -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] 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 KRVZOVMT5SmT for ; Sun, 3 Apr 2016 16:08:36 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7553812D0DE for ; Sun, 3 Apr 2016 16:08:36 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:1d73:b79a:1be2:ecb7]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8D192A809B; Mon, 4 Apr 2016 01:08:32 +0200 (CEST) Message-ID: <5701A26D.6050905@tzi.org> Date: Sun, 03 Apr 2016 20:08:29 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <57004973.3060903@tzi.org> <000901d18d40$b50ebb80$1f2c3280$@augustcellars.com> In-Reply-To: <000901d18d40$b50ebb80$1f2c3280$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] Agenda for IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 23:08:38 -0000 I'd rather go to CFRG myself... Yes, that conflict is a problem. (Putting in CFRG only as a third-level conflict was not so bright, sorry about that.) Unfortunately, Friday is our longer slot. If we move security to Tuesday, most of the WG documents will need to go to Friday, and that takes from the hallway time we may need to resolve tough issues on things we want to ship soon. So I think we should try to find the subset of the work that really needs to be done on Tuesday (< 20 minutes) and leave the rest on Friday. Stay tuned... Grüße, Carsten Jim Schaad wrote: > Putting the security documents on Friday against CFRG is a good way of ensuring that some of the security people are going to be absent. Me among them. > > Jim > > >> -----Original Message----- >> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann >> Sent: Saturday, April 02, 2016 7:37 PM >> To: core@ietf.org WG >> Subject: [core] Agenda for IETF95 >> >> The agenda that is on the github wiki now also is at the official place: >> >> https://www.ietf.org/proceedings/95/agenda/agenda-95-core >> >> Presenters/discussion leaders: Please check the slots; please submit slides by >> COB Sunday (or COB Wednesday if you cannot do this and your slot is on the >> Friday). >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > > From nobody Mon Apr 4 04:12:16 2016 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 17B6012D1BA; Mon, 4 Apr 2016 04:12:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404111215.15622.62986.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 04:12:15 -0700 Archived-At: Cc: core-chairs@ietf.org, The IESG , core@ietf.org Subject: [core] WG Action: Rechartered Constrained RESTful Environments (core) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:12:15 -0000 The Constrained RESTful Environments (core) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Constrained RESTful Environments (core) ----------------------------------------------------------------------- Current status: Active WG Chairs: Carsten Bormann Andrew McGregor Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: core@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Charter: https://datatracker.ietf.org/doc/charter-ietf-core/ CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Milestones: Oct 2013 - Blockwise transfers in CoAP submitted to IESG Jan 2014 - Best Practices for HTTP-CoAP Mapping Implementation submitted to IESG Jan 2014 - Representing CoRE Link Collections in JSON submitted to IESG May 2014 - CoRE Interfaces submitted to IESG Dec 2099 - HOLD (date TBD) Constrained security bootstrapping specification submitted to IESG From nobody Mon Apr 4 04:56:57 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57AE12D5B4 for ; Mon, 4 Apr 2016 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.164, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Xv3bBaf6fH29 for ; Mon, 4 Apr 2016 04:56:54 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 733D812D563 for ; Mon, 4 Apr 2016 04:56:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DOAQAgVgJX/wQXEqxdhAp9h2GzRgENgXIXAQuFaoFrFAEBAQEBAQGBDIRBAQEBex0HBgQDAQIoTQcCGQgbiBqqLQEBAZIZKoR3Z4UMhCc4DYIbS4JDBY1Nc4lBgVKEIYl9ToN/iFqPGh4BAYQxZAGIJQEBAQ X-IPAS-Result: A2DOAQAgVgJX/wQXEqxdhAp9h2GzRgENgXIXAQuFaoFrFAEBAQEBAQGBDIRBAQEBex0HBgQDAQIoTQcCGQgbiBqqLQEBAZIZKoR3Z4UMhCc4DYIbS4JDBY1Nc4lBgVKEIYl9ToN/iFqPGh4BAYQxZAGIJQEBAQ X-IronPort-AV: E=Sophos;i="5.24,440,1454956200"; d="scan'208";a="70754493" To: core@ietf.org MIME-Version: 1.0 X-KeepSent: 0DBE139D:396C10DC-65257F8B:004137DA; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Mon, 4 Apr 2016 17:26:19 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF926 | March 31, 2016) at 04/04/2016 17:26:21, Serialize complete at 04/04/2016 17:26:21 Content-Type: multipart/alternative; boundary="=_alternative 0041945865257F8B_=" Archived-At: Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:56:56 -0000 This is a multipart message in MIME format. --=_alternative 0041945865257F8B_= Content-Type: text/plain; charset="US-ASCII" Dear list, A new version of the No-Response draft has been submitted addressing the final review comments received through the RFC editor's desk. This document is now in RFC editor's queue through the individual submission track. Thanks to Matthias for the review comments. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM ----- From: internet-drafts@ietf.org To: "Soma Bandyopadhyay" , "Abhijan Bhattacharyya" , "Arpan Pal" , "Tulika Bose" Date: 04/04/2016 05:18 PM Subject: New Version Notification for draft-tcs-coap-no-response-option-15.txt A new version of I-D, draft-tcs-coap-no-response-option-15.txt has been successfully submitted by Abhijan Bhattacharyya and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 15 Title: CoAP option for no server-response Document date: 2016-04-04 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt Status: https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ Htmlized: https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15 Diff: https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15 Abstract: There can be M2M scenarios where responses from a server against requests from client are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating a bulk of resources simultaneously, or updating a resource with a very high frequency. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request". This specification introduces a CoAP option called 'No-Response'. Using this option the client can explicitly tell the server to suppress all responses against the particular request. This option also provides granular control to enable suppression of a particular class of response or a combination of response-classes. This option may be effective for both unicast and multicast requests. This document also discusses a few exemplary applications which benefit from this option. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat =====-----=====-----===== 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 0041945865257F8B_= Content-Type: text/html; charset="US-ASCII" Dear list,
A new version of the No-Response draft has been submitted addressing the final review comments received through the RFC editor's desk. This document is now in RFC editor's queue through the individual submission track.
Thanks to Matthias for the review comments.

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________
----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM -----

From:        internet-drafts@ietf.org
To:        "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal" <arpan.pal@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com>
Date:        04/04/2016 05:18 PM
Subject:        New Version Notification for draft-tcs-coap-no-response-option-15.txt




A new version of I-D, draft-tcs-coap-no-response-option-15.txt
has been successfully submitted by Abhijan Bhattacharyya and posted to the
IETF repository.

Name:                                  draft-tcs-coap-no-response-option
Revision:                 15
Title:                                  CoAP option for no server-response
Document date:                 2016-04-04
Group:                                  Individual Submission
Pages:                                  18
URL:            https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt
Status:         https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
Htmlized:       https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15
Diff:           https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15

Abstract:
  There can be M2M scenarios where responses from a server against
  requests from client are redundant. This kind of open-loop exchange
  (with no response path from the server to the client) may be desired
  to minimize resource consumption in constrained systems while
  updating a bulk of resources simultaneously, or updating a resource
  with a very high frequency. CoAP already provides Non-confirmable
  (NON) messages that are not acknowledged by the recipient. However,
  the request/response semantics still require the server to respond
  with a status code indicating "the result of the attempt to
  understand and satisfy the request".

  This specification introduces a CoAP option called 'No-Response'.
  Using this option the client can explicitly tell the server to
  suppress all responses against the particular request. This option
  also provides granular control to enable suppression of a particular
  class of response or a combination of response-classes. This option
  may be effective for both unicast and multicast requests. This
  document also discusses a few exemplary applications which benefit
  from this option.

                                                                                 


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

The IETF Secretariat

=====-----=====-----=====
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 0041945865257F8B_=-- From nobody Mon Apr 4 07:30:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF112D737 for ; Mon, 4 Apr 2016 07:30:49 -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] 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 8g4Sc-8WTJWQ for ; Mon, 4 Apr 2016 07:30:39 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C3012D734 for ; Mon, 4 Apr 2016 07:30:39 -0700 (PDT) Received: from dhcp-a15e.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:8521:2c8c:1564:222d]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2087E1720D2; Mon, 4 Apr 2016 16:30:36 +0200 (CEST) Message-ID: <57027A89.3070501@tzi.org> Date: Mon, 04 Apr 2016 11:30:33 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: core@ietf.org References: <57004973.3060903@tzi.org> <000901d18d40$b50ebb80$1f2c3280$@augustcellars.com> <5701A26D.6050905@tzi.org> In-Reply-To: <5701A26D.6050905@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Agenda for IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:30:49 -0000 OK, so I propose to have a 15-minute segment on security requirements on Tuesday; that seems to be the part where a common understanding with a good set of security people is most crucial. Updated agenda at https://www.ietf.org/proceedings/95/agenda/agenda-95-core (and at https://github.com/core-wg/ietf95/wiki ). Grüße, Carsten Carsten Bormann wrote: > I'd rather go to CFRG myself... > > Yes, that conflict is a problem. (Putting in CFRG only as a third-level > conflict was not so bright, sorry about that.) > > Unfortunately, Friday is our longer slot. If we move security to > Tuesday, most of the WG documents will need to go to Friday, and that > takes from the hallway time we may need to resolve tough issues on > things we want to ship soon. > > So I think we should try to find the subset of the work that really > needs to be done on Tuesday (< 20 minutes) and leave the rest on Friday. > > Stay tuned... > > Grüße, Carsten > > > Jim Schaad wrote: >> Putting the security documents on Friday against CFRG is a good way of ensuring that some of the security people are going to be absent. Me among them. >> >> Jim >> >> >>> -----Original Message----- >>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann >>> Sent: Saturday, April 02, 2016 7:37 PM >>> To: core@ietf.org WG >>> Subject: [core] Agenda for IETF95 >>> >>> The agenda that is on the github wiki now also is at the official place: >>> >>> https://www.ietf.org/proceedings/95/agenda/agenda-95-core >>> >>> Presenters/discussion leaders: Please check the slots; please submit slides by >>> COB Sunday (or COB Wednesday if you cannot do this and your slot is on the >>> Friday). >>> >>> Grüße, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> >> > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Mon Apr 4 15:11:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1457612D783 for ; Mon, 4 Apr 2016 15:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOSeiN2ms6y9 for ; Mon, 4 Apr 2016 15:11:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9788512D58B for ; Mon, 4 Apr 2016 15:11:50 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C7BCEB04AD85E for ; Mon, 4 Apr 2016 22:11:44 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u34MBm59026513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 4 Apr 2016 22:11:48 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u34MBmfN032300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Apr 2016 00:11:48 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 00:11:48 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "core@ietf.org" Thread-Topic: CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gg== Date: Mon, 4 Apr 2016 22:11:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_D32866D362C58thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:11:53 -0000 --_000_D32866D362C58thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, A slightly off-topic question -- though not too much, hopefully. One of the LURK [0] proposals is draft-cairns-tls-session-key-interface [1]= . In Section 7.1.2 [2] the authors propose to transport the LURK payloads ove= r CBOR/CoAP (over DTLS/UDP, I guess). Now, a single LURK box could have to handle lots of these requests, potenti= ally in thousands per second, whereas CoAP's default congestion control alg= orithm parameters [3] are, by design, way too conservative to be suitable f= or high-throughput use cases. Is there anyone that has played with CoAP for high-throughput applications = who'd be willing to share his/her experience with the group and the wider I= ETF community? Cheers, thanks very much, t [0] https://www.ietf.org/mail-archive/web/lurk/current/msg00083.html [1] https://datatracker.ietf.org/doc/draft-cairns-tls-session-key-interface [2] https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#s= ection-7.1.2 [3] https://tools.ietf.org/html/rfc7252#section-4.8 --_000_D32866D362C58thomasfossatialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi folks,

A slightly off-topic question -- though not too much, hopefully.

One of the LURK [0] proposals is draft-cairns-tls-session-key-interfac= e [1].

In Section 7.1.2 [2] the authors propose to transport the LURK payload= s over CBOR/CoAP (over DTLS/UDP, I guess).

Now, a single LURK box could have to handle lots of these requests, po= tentially in thousands per second, whereas CoAP's default congestion contro= l algorithm parameters [3] are, by design, way too conservative to be suita= ble for high-throughput use cases.

Is there anyone that has played with CoAP for high-throughput applicat= ions who'd be willing to share his/her experience with the group and the wi= der IETF community?

Cheers, thanks very much,
t


--_000_D32866D362C58thomasfossatialcatellucentcom_-- From nobody Mon Apr 4 15:23:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC45512D58B for ; Mon, 4 Apr 2016 15:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 m__bbEpoCVX1 for ; Mon, 4 Apr 2016 15:23:01 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B95512D190 for ; Mon, 4 Apr 2016 15:23:01 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:c408:2008:80df:fba5]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2D7A7172098; Tue, 5 Apr 2016 00:22:57 +0200 (CEST) Message-ID: <5702E93E.3030005@tzi.org> Date: Mon, 04 Apr 2016 19:22:54 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "Fossati, Thomas (Nokia - GB)" References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:23:03 -0000 > A slightly off-topic question -- though not too much, hopefully. > > One of the LURK [0] proposals is draft-cairns-tls-session-key-interface [1]. > > In Section 7.1.2 [2] the authors propose to transport the LURK payloads > over CBOR/CoAP (over DTLS/UDP, I guess). Interesting. > Now, a single LURK box could have to handle lots of these requests, > potentially in thousands per second, whereas CoAP's default congestion > control algorithm parameters [3] are, by design, way too conservative to > be suitable for high-throughput use cases. That would be an interesting application for CoCoA... > Is there anyone that has played with CoAP for high-throughput > applications who'd be willing to share his/her experience with the group > and the wider IETF community? I think Matthias Kovatsch' Californium still is the record holder for responses per second from a Web Server (a term that I take to include both servers for CoAP and for one of the HTTPs)... The 16-bit message ID is only good for ~ 10^3 requests per second, so a client that needs a higher rate from a single server would need to use multiple port numbers. Grüße, Carsten From nobody Mon Apr 4 15:45:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8876E12D8F4 for ; Mon, 4 Apr 2016 15:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 IDVq_PjAr_MV for ; Mon, 4 Apr 2016 15:45:14 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF0212D901 for ; Mon, 4 Apr 2016 15:45:10 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0075.outbound.protection.outlook.com [213.199.154.75]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-30-QadmnjxAR7SBLsO3UM56oQ-1; Mon, 04 Apr 2016 23:45:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bAbp0mLbThyP9OLlRY3BPE5evyde2UMQ62n2HoytjSA=; b=QPM9NR2DoLm+kByQF3Q0piQYHHVhS8itQOuFPxZPOdXZyrd4eduUcGwUoWOkXEC8V/ey9t8KAFtQDv0pT7jeNuNIweWNjM/aj+71L7DZ0dt/wL/3D50nGu0HzZ2bA7AWwGBidmfZwEO8MII2Bow9rZrpvnd58EA3KF6Nw9zQDBM= Received: from AM4PR08MB1139.eurprd08.prod.outlook.com (10.167.92.7) by AM4PR08MB1140.eurprd08.prod.outlook.com (10.167.92.8) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 4 Apr 2016 22:45:05 +0000 Received: from AM4PR08MB1139.eurprd08.prod.outlook.com ([10.167.92.7]) by AM4PR08MB1139.eurprd08.prod.outlook.com ([10.167.92.7]) with mapi id 15.01.0447.027; Mon, 4 Apr 2016 22:45:05 +0000 From: Zach Shelby To: "Fossati, Thomas (Nokia - GB)" Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96acWA Date: Mon, 4 Apr 2016 22:45:05 +0000 Message-ID: <08E20027-6748-4B93-B721-52C2720D25B2@arm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.161.69.53] x-ms-office365-filtering-correlation-id: 3eb21e59-43dc-4b89-82b2-08d35cdac469 x-microsoft-exchange-diagnostics: 1; AM4PR08MB1140; 5:mR/00dSOiNiryshsdwuzauX/0BDUgzsE/uWJrEM7FQupkPSr6hvLNBsBCQajPUiyfvzR+jtZK840qMZBRt+Nk5v3xS2s+20MHpxVLnTgcTGLh2fBR2FBne1H0yLb6d2DiOM+GeWR4PIVwoe19QCRIQ==; 24:Vl0a3oRnZeq5ZMqKkBhf9u+TaVk3DTxSxHQYsfjLDdNci9Qm9p//D/X27OlWiuuMOmc1j3+8vKCMN5VmJs8nRLVYrhsv4T0IeyH6YFVdA8k=; 20:3CiwqRAyqgOgXXgvcs9F7NA6R1woDOyiABg+Eh/BDbHFxIc/PI2+9Ss9K7GaRWoPYANUJPPMVh8w2urTm2y4Bzdw0VIX2g4dmeC4G0HgVLG/MANDtb91+K9iJVKv/SK/2k5L9IxmAs0BX3jbgL69Rqir6cwnU7tIG9wh9fM5HpI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR08MB1140; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR08MB1140; BCL:0; PCL:0; RULEID:; SRVR:AM4PR08MB1140; x-forefront-prvs: 0902222726 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(40434004)(33656002)(16236675004)(5002640100001)(5890100001)(50986999)(2906002)(87936001)(3846002)(102836003)(106116001)(586003)(1096002)(6116002)(86362001)(2950100001)(1220700001)(2900100001)(50226001)(5004730100002)(66066001)(92566002)(110136002)(11100500001)(19580395003)(122556002)(5008740100001)(189998001)(36756003)(83716003)(81166005)(3280700002)(3660700001)(19580405001)(82746002)(4326007)(19617315012)(77096005)(76176999)(15975445007)(57306001)(16601075003)(10400500002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR08MB1140; H:AM4PR08MB1139.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2016 22:45:05.5996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB1140 X-MC-Unique: QadmnjxAR7SBLsO3UM56oQ-1 Content-Type: multipart/alternative; boundary="_000_08E2002767484B93B72152C2720D25B2armcom_" Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:45:18 -0000 --_000_08E2002767484B93B72152C2720D25B2armcom_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Indeed, Matthias and I have done considerable work on the scalability of a = single server talking to very large numbers of constrained endpoints [1], h= owever each of those endpoints was NSTART=3D1. I have not seen any work don= e on high throughput between two endpoints, although my knee-jerk reaction = would be that CoAP/TCP or some other TCP based protocol is more suitable. [1] https://www.vs.inf.ethz.ch/publ/papers/mkovatsc-2014-iot-californium.pd= f Zach On 04 Apr 2016, at 15:11, Fossati, Thomas (Nokia - GB) > wrote: Hi folks, A slightly off-topic question -- though not too much, hopefully. One of the LURK [0] proposals is draft-cairns-tls-session-key-interface [1]= . In Section 7.1.2 [2] the authors propose to transport the LURK payloads ove= r CBOR/CoAP (over DTLS/UDP, I guess). Now, a single LURK box could have to handle lots of these requests, potenti= ally in thousands per second, whereas CoAP's default congestion control alg= orithm parameters [3] are, by design, way too conservative to be suitable f= or high-throughput use cases. Is there anyone that has played with CoAP for high-throughput applications = who'd be willing to share his/her experience with the group and the wider I= ETF community? Cheers, thanks very much, t [0] https://www.ietf.org/mail-archive/web/lurk/current/msg00083.html [1] https://datatracker.ietf.org/doc/draft-cairns-tls-session-key-interface [2] https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#s= ection-7.1.2 [3] https://tools.ietf.org/html/rfc7252#section-4.8 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core Zach Shelby Vice President, Marketing ARM Internet of Things BU www.arm.com US: +1 (408) 203-9434 Finland: +358 407796297 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_08E2002767484B93B72152C2720D25B2armcom_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable
Indeed, Matthias and I have done considerable work on the s= calability of a single server talking to very large numbers of constrained = endpoints [1], however each of those endpoints was NSTART=3D1. I have not s= een any work done on high throughput between two endpoints, although my knee-jerk reaction would be that CoAP/T= CP or some other TCP based protocol is more suitable. 

[1] https://www.vs.inf.ethz.ch/pu= bl/papers/mkovatsc-2014-iot-californium.pdf 

Zach

On 04 Apr 2016, at 15:11, Fossati, Thomas (Nokia - GB) <= thomas.fossati@nokia= .com> wrote:

Hi folks,

A slightly off-topic question -- though not too much, hopef= ully.

One of the LURK [0] proposals is draft-cairns-tls-session-k= ey-interface [1].

In Section 7.1.2 [2] the authors propose to transport the L= URK payloads over CBOR/CoAP (over DTLS/UDP, I guess).

Now, a single LURK box could have to handle lots of these r= equests, potentially in thousands per second, whereas CoAP's default conges= tion control algorithm parameters [3] are, by design, way too conservative = to be suitable for high-throughput use cases.

Is there anyone that has played with CoAP for high-throughp= ut applications who'd be willing to share his/her experience with the group= and the wider IETF community?

Cheers, thanks very much,
t

[0] https://www.ietf.org/mail-archive/web= /lurk/current/msg00083.html
[1] https://datatracker.ietf.org/d= oc/draft-cairns-tls-session-key-interface
[2] = https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#secti= on-7.1.2
[3] https://tools.ietf.org/html/rfc7252#section-4.8

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

Zach Shelby
Vice President, Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.li= nkedin.com/in/zachshelby/

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_08E2002767484B93B72152C2720D25B2armcom_-- From nobody Mon Apr 4 15:46:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76012D8D3 for ; Mon, 4 Apr 2016 15:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlsQvaWq9w5i for ; Mon, 4 Apr 2016 15:46:18 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 EDC4E12D5E4 for ; Mon, 4 Apr 2016 15:46:17 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2582632867444; Mon, 4 Apr 2016 22:46:12 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u34MkGYm016840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2016 22:46:16 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u34MkFgQ030770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 00:46:15 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 00:46:16 +0200 From: "Fossati, Thomas (Nokia - GB)" To: EXT Carsten Bormann Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96QgsA///UMQA= Date: Mon, 4 Apr 2016 22:46:15 +0000 Message-ID: References: <5702E93E.3030005@tzi.org> In-Reply-To: <5702E93E.3030005@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:46:20 -0000 Hi Carsten, thanks for the quick reply. On 04/04/2016 19:22, "EXT Carsten Bormann" wrote: >> A slightly off-topic question -- though not too much, hopefully. >>=20 >> One of the LURK [0] proposals is draft-cairns-tls-session-key-interface >>[1]. >>=20 >> In Section 7.1.2 [2] the authors propose to transport the LURK payloads >> over CBOR/CoAP (over DTLS/UDP, I guess). > >Interesting. > >> Now, a single LURK box could have to handle lots of these requests, >> potentially in thousands per second, whereas CoAP's default congestion >> control algorithm parameters [3] are, by design, way too conservative to >> be suitable for high-throughput use cases. > >That would be an interesting application for CoCoA... Is CoCoA available if I'd want to test it? >> Is there anyone that has played with CoAP for high-throughput >> applications who'd be willing to share his/her experience with the group >> and the wider IETF community? > >I think Matthias Kovatsch' Californium still is the record holder for >responses per second from a Web Server (a term that I take to include >both servers for CoAP and for one of the HTTPs)... > >The 16-bit message ID is only good for ~ 10^3 requests per second, so a >client that needs a higher rate from a single server would need to use >multiple port numbers. I haven't re-done the maths, but the CoAP spec has a slightly lower number: "[...] The Message ID is compact; its 16-bit size enables up to about 250 messages per second from one endpoint to another with default protocol parameters.)" Cheers, t From nobody Mon Apr 4 15:52:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2AA12D8EA for ; Mon, 4 Apr 2016 15:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYBJmgsayOV1 for ; Mon, 4 Apr 2016 15:52:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 AE53E12D8D7 for ; Mon, 4 Apr 2016 15:52:43 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id D47D3A6ACB130; Mon, 4 Apr 2016 22:52:36 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u34MqeKt011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Apr 2016 22:52:40 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u34MqeOx021238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 00:52:40 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 00:52:40 +0200 From: "Fossati, Thomas (Nokia - GB)" To: Zach Shelby Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96acWA//+uRIA= Date: Mon, 4 Apr 2016 22:52:39 +0000 Message-ID: References: <08E20027-6748-4B93-B721-52C2720D25B2@arm.com> In-Reply-To: <08E20027-6748-4B93-B721-52C2720D25B2@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_D328751662C9Fthomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:52:47 -0000 --_000_D328751662C9Fthomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Zach, thanks for the pointer. The problem with TCP is that you don't want one lost packet to block the tr= ain of (totally independent) LURK transactions =97 and as a consequence the= bunch of pending TLS handshakes that are waiting on them for completion. A UDP based transport would be better suited for the LURK use case. One th= at minimise the wire overhead (e.g. by using CBOR/CoAP) would be even bette= r. Cheers, t From: core > on behalf = of Zach Shelby > Date: Monday, 4 April 2016 19:45 To: Thomas Fossati > Cc: "core@ietf.org" > Subject: Re: [core] CoAP for high throughput applications Indeed, Matthias and I have done considerable work on the scalability of a = single server talking to very large numbers of constrained endpoints [1], h= owever each of those endpoints was NSTART=3D1. I have not seen any work don= e on high throughput between two endpoints, although my knee-jerk reaction = would be that CoAP/TCP or some other TCP based protocol is more suitable. [1] https://www.vs.inf.ethz.ch/publ/papers/mkovatsc-2014-iot-californium.pd= f Zach On 04 Apr 2016, at 15:11, Fossati, Thomas (Nokia - GB) > wrote: Hi folks, A slightly off-topic question -- though not too much, hopefully. One of the LURK [0] proposals is draft-cairns-tls-session-key-interface [1]= . In Section 7.1.2 [2] the authors propose to transport the LURK payloads ove= r CBOR/CoAP (over DTLS/UDP, I guess). Now, a single LURK box could have to handle lots of these requests, potenti= ally in thousands per second, whereas CoAP's default congestion control alg= orithm parameters [3] are, by design, way too conservative to be suitable f= or high-throughput use cases. Is there anyone that has played with CoAP for high-throughput applications = who'd be willing to share his/her experience with the group and the wider I= ETF community? Cheers, thanks very much, t [0] https://www.ietf.org/mail-archive/web/lurk/current/msg00083.html [1] https://datatracker.ietf.org/doc/draft-cairns-tls-session-key-interface [2] https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#s= ection-7.1.2 [3] https://tools.ietf.org/html/rfc7252#section-4.8 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core Zach Shelby Vice President, Marketing ARM Internet of Things BU www.arm.com US: +1 (408) 203-9434 Finland: +358 407796297 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_D328751662C9Fthomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Zach, thanks for the pointer.

The problem with TCP is that you don't want one lost packet to block t= he train of (totally independent) LURK transactions =97 and as a consequenc= e the bunch of pending TLS handshakes that are waiting on them for completi= on.

A UDP based transport would be better suited for the LURK use case. &n= bsp;One that minimise the wire overhead (e.g. by using CBOR/CoAP) would be = even better.

Cheers, t

From: core <core-bounces@ietf.org> on behalf of Zach Shelby= <Zach.Shelby@arm.com>
Date: Monday, 4 April 2016 19:45 To: Thomas Fossati <thomas.fossati@alcatel-lucent.com<= /a>>
Cc: "core@ietf.org" <core@i= etf.org>
Subject: Re: [core] CoAP for high t= hroughput applications

Indeed, Matthias and I have done considerable work on the s= calability of a single server talking to very large numbers of constrained = endpoints [1], however each of those endpoints was NSTART=3D1. I have not s= een any work done on high throughput between two endpoints, although my knee-jerk reaction would be that CoAP/T= CP or some other TCP based protocol is more suitable. 

[1] https://www.vs.inf.ethz.ch/pu= bl/papers/mkovatsc-2014-iot-californium.pdf 

Zach

On 04 Apr 2016, at 15:11, Fossati, Thomas (Nokia - GB) <= thomas.fossati@nokia= .com> wrote:

Hi folks,

A slightly off-topic question -- though not too much, hopef= ully.

One of the LURK [0] proposals is draft-cairns-tls-session-k= ey-interface [1].

In Section 7.1.2 [2] the authors propose to transport the L= URK payloads over CBOR/CoAP (over DTLS/UDP, I guess).

Now, a single LURK box could have to handle lots of these r= equests, potentially in thousands per second, whereas CoAP's default conges= tion control algorithm parameters [3] are, by design, way too conservative = to be suitable for high-throughput use cases.

Is there anyone that has played with CoAP for high-throughp= ut applications who'd be willing to share his/her experience with the group= and the wider IETF community?

Cheers, thanks very much,
t

[0] https://www.ietf.org/mail-archive/web= /lurk/current/msg00083.html
[1] https://datatracker.ietf.org/d= oc/draft-cairns-tls-session-key-interface
[2] = https://tools.ietf.org/html/draft-cairns-tls-session-key-interface-01#secti= on-7.1.2
[3] https://tools.ietf.org/html/rfc7252#section-4.8

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

Zach Shelby
Vice President, Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.li= nkedin.com/in/zachshelby/

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--_000_D328751662C9Fthomasfossatialcatellucentcom_-- From nobody Mon Apr 4 18:46:41 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5950212D0BF; Mon, 4 Apr 2016 18:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6pJXcJgn0R8; Mon, 4 Apr 2016 18:46:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B4EED12D0A7; Mon, 4 Apr 2016 18:46:34 -0700 (PDT) Received: from localhost ([::1]:40879 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1anG4g-00058h-4b; Mon, 04 Apr 2016 18:46:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 05 Apr 2016 01:46:34 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/397 Message-ID: <065.b1a2e6aa9c5600bacf4cf8ae258078b0@trac.tools.ietf.org> X-Trac-Ticket-ID: 397 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160405014637.B4EED12D0A7@ietfa.amsl.com> Resent-Date: Mon, 4 Apr 2016 18:46:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #397 (coap-tcp-tls): CON usage with CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 01:46:39 -0000 #397: CON usage with CoAP over TCP In http://www.ietf.org/mail-archive/web/core/current/msg06988.html Timothy wrote: ---------------------------------------------------------- In section 4 Message Format says: The ’Message Length’ field is a 16-bit unsigned integer in network byte order. It provides the length of the subsequent CoAP message (including the CoAP header but excluding this message length field) in bytes (so its minimum value is 2). The Message ID and message type are meaningless and thus elided (what would have been the message type field is always filled with what would be the code for NON (01)). What would happen if an Application where to place a CON in the message type field. Based on my reading of this text I would expect the message type from the application to be ignored and the transport to put in a NON message. Is that correct? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-coap- Hannes.Tschofenig@gmx.net | tcp-tls@ietf.org Type: protocol defect | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Mon Apr 4 19:42:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C912D1CA; Mon, 4 Apr 2016 19:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOhxvD8W9Z2w; Mon, 4 Apr 2016 19:42:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 8641A12D0C3; Mon, 4 Apr 2016 19:42:28 -0700 (PDT) Received: from localhost ([::1]:42776 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1anGwm-00050A-05; Mon, 04 Apr 2016 19:42:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 05 Apr 2016 02:42:27 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/389#comment:1 Message-ID: <069.6b5b930f96d1c0eba6b2eb503df78881@trac.tools.ietf.org> References: <054.3b28ae9836a9adbe6ce0269929f27b0f@trac.tools.ietf.org> X-Trac-Ticket-ID: 389 In-Reply-To: <054.3b28ae9836a9adbe6ce0269929f27b0f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160405024228.8641A12D0C3@ietfa.amsl.com> Resent-Date: Mon, 4 Apr 2016 19:42:28 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #389 (coap-tcp-tls): Version negotiation X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:42:30 -0000 #389: Version negotiation Comment (by Hannes.Tschofenig@gmx.net): Clarification from Klaus: http://www.ietf.org/mail-archive/web/core/current/msg06947.html In CoAP, we have the Uri-Host Option [1] which can be included in CoAP requests to indicate the FQDN of the server. In CoAP over UDP a client can target a different virtual server with each request. In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. The question is what CoAP over TCP should do. One option is to include a Uri-Host option in each request, like CoAP over UDP. Then only one connection would be needed for all virtual servers running on the same IP address. Another option is to add a minimal handshake-like message to CoAP over TCP. I have no particular preference, but I think it's important that CoAP over TCP, TLS and WebSockets are consistent and no protocol behaves wildly different from the others. [1] https://tools.ietf.org/html/rfc7252#section-5.10.1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap-tcp- hartke@tzi.org | tls@ietf.org Type: protocol | Status: new defect | Milestone: Priority: minor | Version: Component: coap-tcp- | Resolution: tls | Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Mon Apr 4 19:47:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA612D0C3; Mon, 4 Apr 2016 19:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tywg3Xc2xnj2; Mon, 4 Apr 2016 19:47:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 610E612D176; Mon, 4 Apr 2016 19:47:11 -0700 (PDT) Received: from localhost ([::1]:43009 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1anH1L-00018a-7r; Mon, 04 Apr 2016 19:47:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 05 Apr 2016 02:47:11 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:1 Message-ID: <069.4bcb88e9201e684519e6cc58401a168a@trac.tools.ietf.org> References: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org> X-Trac-Ticket-ID: 391 In-Reply-To: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160405024711.610E612D176@ietfa.amsl.com> Resent-Date: Mon, 4 Apr 2016 19:47:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #391 (coap-tcp-tls): Server name indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:47:13 -0000 #391: Server name indication Comment (by Hannes.Tschofenig@gmx.net): Clarification from Klaus: http://www.ietf.org/mail-archive/web/core/current/msg06947.html In CoAP, we have the Uri-Host Option [1] which can be included in CoAP requests to indicate the FQDN of the server. In CoAP over UDP a client can target a different virtual server with each request. In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. The question is what CoAP over TCP should do. One option is to include a Uri-Host option in each request, like CoAP over UDP. Then only one connection would be needed for all virtual servers running on the same IP address. Another option is to add a minimal handshake-like message to CoAP over TCP. I have no particular preference, but I think it's important that CoAP over TCP, TLS and WebSockets are consistent and no protocol behaves wildly different from the others. [1] https://tools.ietf.org/html/rfc7252#section-5.10.1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap-tcp- hartke@tzi.org | tls@ietf.org Type: other | Status: new technical | Milestone: Priority: minor | Version: Component: coap-tcp- | Resolution: tls | Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Mon Apr 4 19:50:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BB112D651; Mon, 4 Apr 2016 19:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtZk3ZW5tT2S; Mon, 4 Apr 2016 19:50:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 34E4912D63D; Mon, 4 Apr 2016 19:50:16 -0700 (PDT) Received: from localhost ([::1]:43125 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1anH4K-0007jN-29; Mon, 04 Apr 2016 19:50:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Tue, 05 Apr 2016 02:50:16 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/395#comment:1 Message-ID: <069.8b1d47a2e85bb9e67c3581bf4f771043@trac.tools.ietf.org> References: <054.c9e708f420e3b5d1c3d469cf6a66a31c@trac.tools.ietf.org> X-Trac-Ticket-ID: 395 In-Reply-To: <054.c9e708f420e3b5d1c3d469cf6a66a31c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160405025016.34E4912D63D@ietfa.amsl.com> Resent-Date: Mon, 4 Apr 2016 19:50:16 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #395 (coap-tcp-tls): Session resumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 02:50:18 -0000 #395: Session resumption Comment (by Hannes.Tschofenig@gmx.net): In http://www.ietf.org/mail-archive/web/core/current/msg06909.html Hannes assumed that the question was about TLS session resumption. Instead the question focused on TCP, as Klaus clarified in http://www.ietf.org/mail- archive/web/core/current/msg06948.html ------------------- > When DTLS / TLS client communicates with a server then it typically > establishes a session cache to allow session resumption. [...] To clarify, the question is about sessions at the CoAP level, not at the DTLS/TLS level. Should it be possible to send a CoAP request, close the TCP connection, reconnect and receive the response? ------------- Both Klaus and Carsten subsequently agree that there is no expectation that a re-connect from the client would allow it to retrieve (buffered) data. Instead the connection lifetime is bound to the TCP connection. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap-tcp- hartke@tzi.org | tls@ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: minor | Version: Component: coap-tcp- | Resolution: tls | Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Apr 5 05:14:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5212D550; Tue, 5 Apr 2016 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWTugzyf9UcM; Tue, 5 Apr 2016 05:13:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 872A312D545; Tue, 5 Apr 2016 05:13:59 -0700 (PDT) Received: from localhost ([::1]:33271 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1anPrk-0004xh-4N; Tue, 05 Apr 2016 05:13:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, hartke@tzi.org X-Trac-Project: core Date: Tue, 05 Apr 2016 12:13:52 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:2 Message-ID: <069.c6dc1ceaefe1c3013a55fe7446224676@trac.tools.ietf.org> References: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org> X-Trac-Ticket-ID: 391 In-Reply-To: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org Resent-Message-Id: <20160405121359.872A312D545@ietfa.amsl.com> Resent-Date: Tue, 5 Apr 2016 05:13:59 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: Re: [core] #391 (coap-tcp-tls): Server name indication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:14:03 -0000 #391: Server name indication Comment (by hartke@tzi.org): Related: HTTP/2 allows the reuse of connections for different origins: Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address. http://tools.ietf.org/html/rfc7540#section-9.1.1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap-tcp- hartke@tzi.org | tls@ietf.org Type: other | Status: new technical | Milestone: Priority: minor | Version: Component: coap-tcp- | Resolution: tls | Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From nobody Tue Apr 5 08:09:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB85812D13C for ; Tue, 5 Apr 2016 08:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.164, RCVD_IN_DNSWL_MED=-2.3] 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 YJtRgPx49iNw for ; Tue, 5 Apr 2016 08:09:41 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4005E12D0EF for ; Tue, 5 Apr 2016 08:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u35F9bac023367 for ; Tue, 5 Apr 2016 17:09:37 +0200 (CEST) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qfXMP30Lwz38fZ for ; Tue, 5 Apr 2016 17:09:37 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id u206so8508552wme.1 for ; Tue, 05 Apr 2016 08:09:37 -0700 (PDT) X-Gm-Message-State: AD7BkJJJlaRt/sAeGs+kA8ZYPLgYGhw3PdzGRffglX+m1eKGIeCyj0FZ231+LTQrVVWcfSMQqkZrcg4Mm0FOOA== X-Received: by 10.28.156.10 with SMTP id f10mr1985146wme.42.1459868976993; Tue, 05 Apr 2016 08:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Tue, 5 Apr 2016 08:08:57 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 5 Apr 2016 17:08:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Abhijan Bhattacharyya Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:09:43 -0000 Hi Abhijan, I've taken a brief look at the new revision. It worries me that the draft does not contain the words "safe-to-forward", "proxy" (besides HTTP-to-CoAP reverse proxy) and "cache". The interaction of a new option with these CoAP features is an important aspect and needs careful analysis. I don't think it's a good idea to publish the draft as an RFC before the text addresses the following questions: * What's the rationale for the No-Response option being safe-to-forward? * What's the impact of the No-Response option on a chain of CoAP-to-CoAP proxies? * What's the impact of the No-Response option on caches? Klaus On 4 April 2016 at 13:56, Abhijan Bhattacharyya wrote: > Dear list, > A new version of the No-Response draft has been submitted addressing the > final review comments received through the RFC editor's desk. This document > is now in RFC editor's queue through the individual submission track. > Thanks to Matthias for the review comments. > > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM > ----- > > From: internet-drafts@ietf.org > To: "Soma Bandyopadhyay" , "Abhijan > Bhattacharyya" , "Arpan Pal" > , "Tulika Bose" > Date: 04/04/2016 05:18 PM > Subject: New Version Notification for > draft-tcs-coap-no-response-option-15.txt > ________________________________ > > > > > A new version of I-D, draft-tcs-coap-no-response-option-15.txt > has been successfully submitted by Abhijan Bhattacharyya and posted to the > IETF repository. > > Name: draft-tcs-coap-no-response-option > Revision: 15 > Title: CoAP option for no server-response > Document date: 2016-04-04 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt > Status: > https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ > Htmlized: > https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15 > > Abstract: > There can be M2M scenarios where responses from a server against > requests from client are redundant. This kind of open-loop exchange > (with no response path from the server to the client) may be desired > to minimize resource consumption in constrained systems while > updating a bulk of resources simultaneously, or updating a resource > with a very high frequency. CoAP already provides Non-confirmable > (NON) messages that are not acknowledged by the recipient. However, > the request/response semantics still require the server to respond > with a status code indicating "the result of the attempt to > understand and satisfy the request". > > This specification introduces a CoAP option called 'No-Response'. > Using this option the client can explicitly tell the server to > suppress all responses against the particular request. This option > also provides granular control to enable suppression of a particular > class of response or a combination of response-classes. This option > may be effective for both unicast and multicast requests. This > document also discusses a few exemplary applications which benefit > from this option. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > =====-----=====-----===== > 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 > From nobody Tue Apr 5 09:20:47 2016 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 053A012D750 for ; Tue, 5 Apr 2016 09:20:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405162046.25931.13298.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 09:20:46 -0700 From: IETF Secretariat Archived-At: Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:20:46 -0000 Changed milestone "Blockwise transfers in CoAP submitted to IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/core/charter/ From nobody Tue Apr 5 09:38:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5448912D762 for ; Tue, 5 Apr 2016 09:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGJzXMHxBF9P for ; Tue, 5 Apr 2016 09:38:12 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F8A12D76B for ; Tue, 5 Apr 2016 09:38:07 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 5 Apr 2016 18:38:01 +0200 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0266.001; Tue, 5 Apr 2016 18:38:05 +0200 From: "Kovatsch Matthias" To: "Fossati, Thomas (Nokia - GB)" , "EXT Carsten Bormann" Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96QgsA///UMQCAAX3f4A== Date: Tue, 5 Apr 2016 16:38:04 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54F186325@MBX110.d.ethz.ch> References: <5702E93E.3030005@tzi.org> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:38:14 -0000 > Is CoCoA available if I'd want to test it? Californium has expirmental support for CoCoA (contributed by August Betzle= r). The focus, however, was actual congestion in constrained networks, and = not high-throughput. Hence, the CoCoA implementation isn't for that... > I haven't re-done the maths, but the CoAP spec has a slightly lower numbe= r: >=20 > "[...] The Message ID > is compact; its 16-bit size enables up to about 250 messages per > second from one endpoint to another with default protocol > parameters.)" This only limits the number of messages between two endpoints. A server can= receive this rate from an arbitrary number of clients. I think this was th= e scenario for this LURK box, no? In case you really need to send a higher rate of requests from a client, it= could use multiple ports. Ciao Matthias From nobody Tue Apr 5 09:58:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828A12D7C4 for ; Tue, 5 Apr 2016 09:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 6s604MFTLCrz for ; Tue, 5 Apr 2016 09:57:57 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A494E12D7D7 for ; Tue, 5 Apr 2016 09:57:55 -0700 (PDT) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id D8B3541C099; Tue, 5 Apr 2016 18:57:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qzZge6m02Wt0; Tue, 5 Apr 2016 18:57:52 +0200 (CEST) X-Originating-IP: 31.133.160.124 Received: from dhcp-a07c.meeting.ietf.org (dhcp-a07c.meeting.ietf.org [31.133.160.124]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id DD0AD41C07F; Tue, 5 Apr 2016 18:57:50 +0200 (CEST) Message-ID: <5703EE8B.5050509@tzi.org> Date: Tue, 05 Apr 2016 13:57:47 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Kovatsch Matthias References: <5702E93E.3030005@tzi.org> <55877B3AFB359744BA0F2140E36F52B54F186325@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54F186325@MBX110.d.ethz.ch> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:57:59 -0000 Kovatsch Matthias wrote: > In case you really need to send a higher rate of requests from a client, it could use multiple ports. ... and it is worth noting that distributing requests over a large number of outgoing ports is something that DNS servers and resolvers know to do well. It seems to me the need to change anything about the message-ID here is very low even for high-rate applications. Grüße, Carsten From nobody Tue Apr 5 10:38:40 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2424312D799 for ; Tue, 5 Apr 2016 10:38:38 -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] 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 hemmXDEsIFyK for ; Tue, 5 Apr 2016 10:38:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBCC12D612 for ; Tue, 5 Apr 2016 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u35HcX2f027317 for ; Tue, 5 Apr 2016 19:38:33 +0200 (CEST) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qfbgF2RJvz397l for ; Tue, 5 Apr 2016 19:38:33 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id n3so31363309wmn.0 for ; Tue, 05 Apr 2016 10:38:33 -0700 (PDT) X-Gm-Message-State: AD7BkJIOWxrUo0etgqkWhaxZLSmlTM/Tt+xWHJBJ9Kypti/3ib7d3ffA+wBxBqBajUKMVsOIO7dyWC2UXkrJ8g== X-Received: by 10.194.158.98 with SMTP id wt2mr17073424wjb.102.1459877912982; Tue, 05 Apr 2016 10:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Tue, 5 Apr 2016 10:37:53 -0700 (PDT) In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BA61E93@NABESITE.InterDigital.com> References: <55F83752.3090609@tzi.org> <36F5869FE31AB24485E5E3222C288E1F5BA61E93@NABESITE.InterDigital.com> From: Klaus Hartke Date: Tue, 5 Apr 2016 19:37:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:38:38 -0000 Hi! I've reviewed the new -08 revision of the draft and am quite happy with the outcome. There is just one thing that I think is quite critical: Akbar Rahman wrote: > We will clarify that the whole section 5 is only for the special > (optional) case where a CoAP URI is embedded within the HTTP URI by > the HTTP client. The other case is when only a "pure" HTTP URI is > sent by the HTTP client to the HC proxy, and the HC proxy itself > generates the CoAP URI. In this second case the whole section 5 is > not required. > > Specifically, the case where the HTTP client embeds the CoAP URI info > into the HTTP URI as we describe in Section 5 will map implicitly to > our 1st use case in section 4. On the other hand, our 2nd use case in > section 4 implies that the legacy application probably does not embed > the CoAP URI info into the HTTP URI as it is legacy and was written > without CoAP support. So in this case, section 5 does not imply but > sections 6 and 7 do apply. We definitely need to clarify these > different possible scenarios of "pure reverse proxy" vs the other case > of embedded CoAP URI info in the HTTP request. This is a great clarification of the scope and purpose of the document, and the bit I was missing all the time. Add it to the introduction? It's currently only mentioned in section 4, quite far into the document. The only problem is: the case where the HTTP client actively embeds a CoAP URI within a HTTP URI is *not* a reverse proxy. Don't get me wrong. I think this is a valid use case and I'm not against its inclusion in the document. But you can't call it a reverse proxy. It doesn't even match your own definition of reverse proxy in the document ("This mechanism is transparent to the client, which may assume that it is communicating with the intended target HTTP server. In other words, the client accesses the proxy as an origin server [...]"). Only what you describe as a "pure reverse proxy" with a "legacy HTTP client without CoAP support" is really a reverse proxy. Can you find a better term for this kind of service? Maybe something like "HTTP Access Interface to CoAP"? Klaus From nobody Tue Apr 5 11:05:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949B12D612 for ; Tue, 5 Apr 2016 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 jZH1gxAdYtDi for ; Tue, 5 Apr 2016 11:05:23 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D988412D605 for ; Tue, 5 Apr 2016 11:05:22 -0700 (PDT) Received: from dhcp-a07c.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:2c64:467:1893:6db2]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id D1484172097; Tue, 5 Apr 2016 20:05:19 +0200 (CEST) Message-ID: <5703FE5C.5080902@tzi.org> Date: Tue, 05 Apr 2016 15:05:16 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] IETF 95 slides X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:05:24 -0000 The first set of consolidated slides is out at: https://www.ietf.org/proceedings/95/slides/slides-95-core-0.pdf Slot discussion leaders: Is everything in there that you need to lead the discussion? Are there updates to those slides? Grüße, Carsten From nobody Tue Apr 5 11:52:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078B12D134 for ; Tue, 5 Apr 2016 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.164, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 azBqxSGjhVpd for ; Tue, 5 Apr 2016 11:52:31 -0700 (PDT) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1179012D16A for ; Tue, 5 Apr 2016 11:52:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DRAQCwBwRX/wQXEqxegmuBH32HYawMh0sBDYFyFwELghYBg1MCgXgUAQEBAQEBAYEMhEEBAQEDAQEBASZFCQIFCwsHBgQDAQIBJwcnHwkIBgsIG4gEFq1rAQEBkk0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ2EJzgMAYJ+gisFh2+FXnOJQYFShCGFXoQfFzeDf4hajxoeAQGCdIE/ZAGINgEBAQ X-IPAS-Result: A2DRAQCwBwRX/wQXEqxegmuBH32HYawMh0sBDYFyFwELghYBg1MCgXgUAQEBAQEBAYEMhEEBAQEDAQEBASZFCQIFCwsHBgQDAQIBJwcnHwkIBgsIG4gEFq1rAQEBkk0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhHdnhQ2EJzgMAYJ+gisFh2+FXnOJQYFShCGFXoQfFzeDf4hajxoeAQGCdIE/ZAGINgEBAQ X-IronPort-AV: E=Sophos;i="5.24,445,1454956200"; d="scan'208";a="71328917" X-DISCLAIMER: FALSE In-Reply-To: References: To: Klaus Hartke MIME-Version: 1.0 Importance: High X-KeepSent: 4891E172:E728883C-65257F8C:0064E7F4; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: Abhijan Bhattacharyya Date: Wed, 6 Apr 2016 00:22:19 +0530 X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF926 | March 31, 2016) at 04/06/2016 00:22:21, Serialize complete at 04/06/2016 00:22:21 Content-Type: multipart/alternative; boundary="=_alternative 0067AA6365257F8C_=" Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:52:34 -0000 This is a multipart message in MIME format. --=_alternative 0067AA6365257F8C_= Content-Type: text/plain; charset="US-ASCII" Hi Klaus, Thanks for your comments. Actually, yesterday I got to know from Matthias that you have rightly pointed out the safe-to-forward issue. I have taken some action on the draft and shared the modified text with Carsten and Matthias earlier today. I really should have included you as well. Sorry about that. The option should be Unsafe-to-forward. The option definition has been modified as below: " The properties of No-Response option are given in Table 1. +--------+---+---+---+---+-------------+--------+--------+---------+ | Number | C | U | N | R | Name | Format | Length | Default | +--------+---+---+---+---+-------------+--------+--------+---------+ | 258 | | X | - | | No-Response | uint | 0-1 | 0 | +--------+---+---+---+---+-------------+--------+--------+---------+ Table 1: Option Properties This option is a request option. It is Elective and Non-Repeatable. This option is Unsafe-to-forward as the intermediary MUST know how to interpret this option. Otherwise the intermediary, without knowledge about the special unidirectional nature of the request, would wait for responses. " Now regarding the other two points: >> What's the impact of the No-Response option on a chain of CoAP-to-CoAP proxies? Since, this option is unsafe-to-forward, the intermediaries must have knowledge about the option. So, the intermediaries should not wait for any responses if the option value is 127. For granular suppression it should wait for up to some given time out as described in the "Note" in section 2.1. >> What's the impact of the No-Response option on caches? Since the cacheability of the CoAP responses depends on the Response Code so the No-Response option should not have any effect on the cacheability. Suppose, we have a request which triggers a cacheable response. But, if the request has No-Response then the response should be cached but will not be delivered to the client (assuming that server has implementation of No-Response). If a similar request without No-Response arrives next time then the response may be delivered from Cache if considered fresh. Does the above sound good? Please share your views. Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Klaus Hartke To: Abhijan Bhattacharyya Cc: "core@ietf.org WG" , Nevil Brownlee Date: 04/05/2016 08:39 PM Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt Hi Abhijan, I've taken a brief look at the new revision. It worries me that the draft does not contain the words "safe-to-forward", "proxy" (besides HTTP-to-CoAP reverse proxy) and "cache". The interaction of a new option with these CoAP features is an important aspect and needs careful analysis. I don't think it's a good idea to publish the draft as an RFC before the text addresses the following questions: * What's the rationale for the No-Response option being safe-to-forward? * What's the impact of the No-Response option on a chain of CoAP-to-CoAP proxies? * What's the impact of the No-Response option on caches? Klaus On 4 April 2016 at 13:56, Abhijan Bhattacharyya wrote: > Dear list, > A new version of the No-Response draft has been submitted addressing the > final review comments received through the RFC editor's desk. This document > is now in RFC editor's queue through the individual submission track. > Thanks to Matthias for the review comments. > > Regards > Abhijan Bhattacharyya > Associate Consultant > Scientist, Innovation Lab, Kolkata, India > Tata Consultancy Services > Mailto: abhijan.bhattacharyya@tcs.com > Website: http://www.tcs.com > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM > ----- > > From: internet-drafts@ietf.org > To: "Soma Bandyopadhyay" , "Abhijan > Bhattacharyya" , "Arpan Pal" > , "Tulika Bose" > Date: 04/04/2016 05:18 PM > Subject: New Version Notification for > draft-tcs-coap-no-response-option-15.txt > ________________________________ > > > > > A new version of I-D, draft-tcs-coap-no-response-option-15.txt > has been successfully submitted by Abhijan Bhattacharyya and posted to the > IETF repository. > > Name: draft-tcs-coap-no-response-option > Revision: 15 > Title: CoAP option for no server-response > Document date: 2016-04-04 > Group: Individual Submission > Pages: 18 > URL: > https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt > Status: > https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ > Htmlized: > https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15 > > Abstract: > There can be M2M scenarios where responses from a server against > requests from client are redundant. This kind of open-loop exchange > (with no response path from the server to the client) may be desired > to minimize resource consumption in constrained systems while > updating a bulk of resources simultaneously, or updating a resource > with a very high frequency. CoAP already provides Non-confirmable > (NON) messages that are not acknowledged by the recipient. However, > the request/response semantics still require the server to respond > with a status code indicating "the result of the attempt to > understand and satisfy the request". > > This specification introduces a CoAP option called 'No-Response'. > Using this option the client can explicitly tell the server to > suppress all responses against the particular request. This option > also provides granular control to enable suppression of a particular > class of response or a combination of response-classes. This option > may be effective for both unicast and multicast requests. This > document also discusses a few exemplary applications which benefit > from this option. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > =====-----=====-----===== > 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 > --=_alternative 0067AA6365257F8C_= Content-Type: text/html; charset="US-ASCII" Hi Klaus,
Thanks for your comments.
Actually, yesterday I got to know from Matthias that you have rightly pointed out the safe-to-forward issue. I have taken some action on the draft and shared the modified text with Carsten and Matthias earlier today. I really should have included you as well. Sorry about that.  

The option should be Unsafe-to-forward. The option definition has been modified as below:

"
The properties of No-Response option are given in Table 1.

+--------+---+---+---+---+-------------+--------+--------+---------+
| Number | C | U | N | R |   Name      | Format | Length | Default |
+--------+---+---+---+---+-------------+--------+--------+---------+
|   258  |   | X | - |   | No-Response |  uint  |  0-1   |    0    |
+--------+---+---+---+---+-------------+--------+--------+---------+
                        Table 1: Option Properties

This option is a request option. It is Elective and Non-Repeatable. This option is Unsafe-to-forward as the intermediary MUST know how to interpret this option. Otherwise the intermediary, without knowledge about the special unidirectional nature of the request, would wait for responses.

"

Now regarding the other two points:
>> What's the impact of the No-Response option on a chain of
CoAP-to-CoAP proxies?

Since, this option is unsafe-to-forward, the intermediaries must have knowledge about the option. So, the intermediaries should not wait for any responses if the option value is 127. For granular suppression it should wait for up to some given time out as described in the "Note" in section 2.1.

>> What's the impact of the No-Response option on caches?
Since the cacheability of the CoAP responses depends on the Response Code so the No-Response option should not have any effect on the cacheability. Suppose, we have a request which triggers a cacheable response. But, if the request has No-Response then the response should be cached but will not be delivered to the client (assuming that server has implementation of No-Response). If a similar request without No-Response arrives next time then the response may be delivered from Cache if considered fresh.

Does the above sound good? Please share your views.    

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________



From:        Klaus Hartke <hartke@tzi.org>
To:        Abhijan Bhattacharyya <abhijan.bhattacharyya@tcs.com>
Cc:        "core@ietf.org WG" <core@ietf.org>, Nevil Brownlee <rfc-ise@rfc-editor.org>
Date:        04/05/2016 08:39 PM
Subject:        Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt




Hi Abhijan,

I've taken a brief look at the new revision. It worries me that the
draft does not contain the words "safe-to-forward", "proxy" (besides
HTTP-to-CoAP reverse proxy) and "cache". The interaction of a new
option with these CoAP features is an important aspect and needs
careful analysis. I don't think it's a good idea to publish the draft
as an RFC before the text addresses the following questions:

* What's the rationale for the No-Response option being safe-to-forward?

* What's the impact of the No-Response option on a chain of
CoAP-to-CoAP proxies?

* What's the impact of the No-Response option on caches?

Klaus


On 4 April 2016 at 13:56, Abhijan Bhattacharyya
<abhijan.bhattacharyya@tcs.com> wrote:
> Dear list,
> A new version of the No-Response draft has been submitted addressing the
> final review comments received through the RFC editor's desk. This document
> is now in RFC editor's queue through the individual submission track.
> Thanks to Matthias for the review comments.
>
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: abhijan.bhattacharyya@tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>
> ----- Forwarded by Abhijan Bhattacharyya/KOL/TCS on 04/04/2016 05:22 PM
> -----
>
> From:        internet-drafts@ietf.org
> To:        "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan
> Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal"
> <arpan.pal@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com>
> Date:        04/04/2016 05:18 PM
> Subject:        New Version Notification for
> draft-tcs-coap-no-response-option-15.txt
> ________________________________
>
>
>
>
> A new version of I-D, draft-tcs-coap-no-response-option-15.txt
> has been successfully submitted by Abhijan Bhattacharyya and posted to the
> IETF repository.
>
> Name:                                  draft-tcs-coap-no-response-option
> Revision:                 15
> Title:                                  CoAP option for no server-response
> Document date:                 2016-04-04
> Group:                                  Individual Submission
> Pages:                                  18
> URL:
> https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-15.txt
> Status:
> https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
> Htmlized:
> https://tools.ietf.org/html/draft-tcs-coap-no-response-option-15
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-tcs-coap-no-response-option-15
>
> Abstract:
>   There can be M2M scenarios where responses from a server against
>   requests from client are redundant. This kind of open-loop exchange
>   (with no response path from the server to the client) may be desired
>   to minimize resource consumption in constrained systems while
>   updating a bulk of resources simultaneously, or updating a resource
>   with a very high frequency. CoAP already provides Non-confirmable
>   (NON) messages that are not acknowledged by the recipient. However,
>   the request/response semantics still require the server to respond
>   with a status code indicating "the result of the attempt to
>   understand and satisfy the request".
>
>   This specification introduces a CoAP option called 'No-Response'.
>   Using this option the client can explicitly tell the server to
>   suppress all responses against the particular request. This option
>   also provides granular control to enable suppression of a particular
>   class of response or a combination of response-classes. This option
>   may be effective for both unicast and multicast requests. This
>   document also discusses a few exemplary applications which benefit
>   from this option.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> =====-----=====-----=====
> 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
>
--=_alternative 0067AA6365257F8C_=-- From nobody Tue Apr 5 13:04:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1212D7FC for ; Tue, 5 Apr 2016 13:04:49 -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] 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 EtWyYtTlZZZu for ; Tue, 5 Apr 2016 13:04:46 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B56712D86D for ; Tue, 5 Apr 2016 13:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u35K4cPh027671 for ; Tue, 5 Apr 2016 22:04:38 +0200 (CEST) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qffvp53Nxz385s for ; Tue, 5 Apr 2016 22:04:38 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id 191so35947872wmq.0 for ; Tue, 05 Apr 2016 13:04:38 -0700 (PDT) X-Gm-Message-State: AD7BkJL1i2SZ20t/crzsuSTd4b81n/F0QAIzZr1Od/va6OjHydqB9yjUn93Eoz/cg9LQCSLPsGfz8XqLvKt8pw== X-Received: by 10.28.128.88 with SMTP id b85mr20611722wmd.46.1459886678185; Tue, 05 Apr 2016 13:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.47.167 with HTTP; Tue, 5 Apr 2016 13:03:58 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 5 Apr 2016 22:03:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Abhijan Bhattacharyya Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nevil Brownlee , "core@ietf.org WG" Subject: Re: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:04:49 -0000 Abhijan Bhattacharyya wrote: > The option should be Unsafe-to-forward. The option definition has been > modified as below: > > "[...] This > option is Unsafe-to-forward as the intermediary MUST know how to interpret > this option. [...]" Unsafe-to-forward does not mean that every intermediary has the requirement to implement your option. Unsafe-to-forward determines the behaviour of intermediaries that do *not* implement an option. If an intermediary receives a request with an unrecognised option that is unsafe-to-forward, then it must not include that option in its request towards the origin server. > Now regarding the other two points: (Note that these points need to be addressed in the document, not just on the mailing list.) >>> What's the impact of the No-Response option on a chain of > CoAP-to-CoAP proxies? > > Since, this option is unsafe-to-forward, the intermediaries must have > knowledge about the option. No. See above. > So, the intermediaries should not wait for any > responses if the option value is 127. What do you mean? If an intermediary receives a request with the No-Response option, should it include the option in its request towards the origin server? That's a bad idea. See below. And a client should probably listen to responses even if it suppresses all responses because a server might still want to send a response, e.g., to slow down the client. See below. >>> What's the impact of the No-Response option on caches? > > Since the cacheability of the CoAP responses depends on the Response Code so > the No-Response option should not have any effect on the cacheability. If a server returns a 4.04 response (or any other cacheable error response) with Max-Age != 0, then a cache will return that response as long as Max-Age has not elapsed instead of making a request towards the origin server. So the caching of error responses protects a server a bit from clients repeatedly triggering the same error. The No-Response option destroys this protection. To limit the damage, I would say that intermediaries MUST NOT include the No-Response option in their requests. How does the No-Response option interact with the 4.29 response code [1]? I would expect that a server is permitted to send this response even if the client suppresses this response code. An unrelated nit: Section 2.1 says "To suppress all possible responses: The maximum reserved response code for CoAP is 7.31". The range 6.00 to 7.31 is reserved, but not for response codes. The maximum response code is 5.31. Klaus [1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-04#section-9.3 From nobody Tue Apr 5 13:27:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB9A12D63A for ; Tue, 5 Apr 2016 13:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ym7sKd4MOt for ; Tue, 5 Apr 2016 13:27:01 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 BF96D12D159 for ; Tue, 5 Apr 2016 13:27:01 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B2F32D0ED12FA; Tue, 5 Apr 2016 20:26:56 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u35KQxNV004113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2016 20:27:00 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u35KQxcx014537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Apr 2016 22:26:59 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 5 Apr 2016 22:26:59 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "EXT Kovatsch Matthias" , EXT Carsten Bormann Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96QgsA///UMQCAAX3f4P//7ZCA Date: Tue, 5 Apr 2016 20:26:58 +0000 Message-ID: References: <5702E93E.3030005@tzi.org> <55877B3AFB359744BA0F2140E36F52B54F186325@MBX110.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54F186325@MBX110.d.ethz.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <1035EAB487E9594B92E7999AAD3B5249@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:27:04 -0000 On 05/04/2016 13:38, "EXT Kovatsch Matthias" wrote: >>I haven't re-done the maths, but the CoAP spec has a slightly lower >>number: >>=20 >> "[...] The Message ID >> is compact; its 16-bit size enables up to about 250 messages per >> second from one endpoint to another with default protocol >> parameters.)" > >This only limits the number of messages between two endpoints. A server >can receive this rate from an arbitrary number of clients. I think this >was the scenario for this LURK box, no? My target is for a *single* edge server to send around 20K transactions per second to the LURK box. >In case you really need to send a higher rate of requests from a client, >it could use multiple ports. So, assuming we can't do anything at the CoAP layer, the number of ephemeral ports that are available on the client is the limiting factor here. IIRC, on Linux that number is roughly 30K, which means that a dedicated box could do >7M transactions per second? That's quite a lot. From nobody Wed Apr 6 00:09:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403FE12D64A for ; Wed, 6 Apr 2016 00:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afTHkhjO40Il for ; Wed, 6 Apr 2016 00:09:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BD012D0B6 for ; Wed, 6 Apr 2016 00:09:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLQ19063; Wed, 06 Apr 2016 07:09:19 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 08:09:16 +0100 Received: from BLREML509-MBB.china.huawei.com ([169.254.1.138]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 12:39:07 +0530 From: Vasu Kantubukta To: "core@ietf.org" Thread-Topic: Does Core defines query parameter "op" Thread-Index: AdGP0zU+efLlvO1gQ2u2TrPw3C2Pog== Date: Wed, 6 Apr 2016 07:09:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.211.249] Content-Type: multipart/alternative; boundary="_000_D6EBB546995C064A9492E8E27F62D90D0AA252EBblreml509mbbchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5704B621.00A4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.138, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 369b8837f35727bd4a062a7a34a017f9 Archived-At: Cc: Ashutosh prakash , Javed siddiqui Subject: [core] Does Core defines query parameter "op" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:09:26 -0000 --_000_D6EBB546995C064A9492E8E27F62D90D0AA252EBblreml509mbbchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Core members, Does core already defined any parameter for querying an operation which can= be performed on device. I mean, for example, if device wants to know that "read temperature" operat= ion is available by any device in the network or not. To achieve this, does= core defines any parameter such as "op" in either core or rd parameter lis= t?. Thanks and Best Regards K Vasu --_000_D6EBB546995C064A9492E8E27F62D90D0AA252EBblreml509mbbchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Core members,

 

Does core already defined any parameter for querying= an operation which can be performed on device.

 

I mean, for example, if device wants to know that &#= 8220;read temperature” operation is available by any device in the ne= twork or not. To achieve this, does core defines any parameter such as R= 20;op” in either core or rd parameter list?.

 

Thanks and Best Regards

K Vasu

 

--_000_D6EBB546995C064A9492E8E27F62D90D0AA252EBblreml509mbbchi_-- From nobody Wed Apr 6 02:58:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1901212D874 for ; Wed, 6 Apr 2016 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1myg4clenQQl for ; Wed, 6 Apr 2016 02:58:53 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA2012D177 for ; Wed, 6 Apr 2016 02:58:52 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id u369wmIx010356; Wed, 6 Apr 2016 11:58:48 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 02B001D53C1; Wed, 6 Apr 2016 11:58:48 +0200 (CEST) Received: from 131.111.5.14 by webmail.entel.upc.edu with HTTP; Wed, 6 Apr 2016 11:58:38 +0200 Message-ID: <54c26e6d388f0ea0564417ffc87a4091.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <5702E93E.3030005@tzi.org> Date: Wed, 6 Apr 2016 11:58:38 +0200 From: "Carles Gomez Montenegro" To: "Fossati, Thomas (Nokia - GB)" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Delayed for 24:13:48 by milter-greylist-4.4.3 (dash.upc.es [147.83.2.50]); Wed, 06 Apr 2016 11:58:49 +0200 (CEST) Archived-At: Cc: ilker.demirkol@entel.upc.edu, august.betzler@googlemail.com, "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 09:58:57 -0000 Hi Thomas, >>> Now, a single LURK box could have to handle lots of these requests, >>> potentially in thousands per second, whereas CoAP's default congestion >>> control algorithm parameters [3] are, by design, way too conservative >>> to >>> be suitable for high-throughput use cases. >> >>That would be an interesting application for CoCoA... > > Is CoCoA available if I'd want to test it? Here you may find the Californium implementation including CoCoA: https://github.com/eclipse/californium As Matthias said, the implementation including CoCoA is not actually optimized for dealing with thousands of requests. However, CoCoA is adaptive and, if network conditions allow it, the algorithm may behave more aggressively than default CoAP's congestion control (while still being safe). In the experiments we have done so far, we have dealt with up to hundreds of requests per second (outperforming default CoAP and also state-of-the-art alternative approaches designed for TCP), since the limitation in our scenarios was the network/channel capacity (e.g. [1, 2]). It would be very interesting to see what happens in a scenario such as the one you describe, where the limitation might not be the network throughput. By the way, feedback on CoCoA would be very much welcome! Thanks, Carles [1] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP congestion control for the Internet of Things", IEEE Communications Magazine (In press). https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control_for_the_Internet_of_Things [2] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoCoA+: an advanced congestion control mechanism for CoAP", Ad-hoc Networks journal, 2015. http://www.sciencedirect.com/science/article/pii/S1570870515000888 From nobody Wed Apr 6 05:10:30 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60E112D9CB for ; Wed, 6 Apr 2016 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsJA2YYlJtDk for ; Wed, 6 Apr 2016 05:10:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 C1E2C12D9CF for ; Wed, 6 Apr 2016 05:10:23 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1850955136DD7; Wed, 6 Apr 2016 12:10:20 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u36CALZr026277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 12:10:21 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u36CAJkp010802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 14:10:20 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 14:10:03 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "Rahman, Akbar" , Klaus Hartke Thread-Topic: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 Thread-Index: AQHQ78oxd7xyjg7Cf06HmyutH/88Dp5R7T+AgP+hgYCALDhUgA== Date: Wed, 6 Apr 2016 12:10:03 +0000 Message-ID: References: <55F83752.3090609@tzi.org> <36F5869FE31AB24485E5E3222C288E1F5BA61E93@NABESITE.InterDigital.com> In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BA61E93@NABESITE.InterDigital.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BF685C05C519E488E21DC275EC51395@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] WG last-call (WGLC) of draft-ietf-core-http-mapping-07 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:10:29 -0000 On 09/03/2016 04:52, "core on behalf of Rahman, Akbar" wrote: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >9.2 -- have you submitted the registration to the media-types@ietf.org >mailing list for review? It's probably a good idea to do this before >sending the document to the IESG. > >Authors? Response #20: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Good point. We will do so shortly. Apropos, is there a registry for link format attributes (e.g. for "rt", "hct")? Cheers, t From nobody Wed Apr 6 08:09:35 2016 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 0033112D8E9; Wed, 6 Apr 2016 08:09:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406150931.25001.51498.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 08:09:31 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-http-mapping-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:09:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Guidelines for HTTP-CoAP Mapping Implementations Authors : Angelo P. Castellani Salvatore Loreto Akbar Rahman Thomas Fossati Esko Dijk Filename : draft-ietf-core-http-mapping-09.txt Pages : 35 Date : 2016-04-06 Abstract: This document provides reference information for implementing a proxy that performs translation between the HTTP protocol and the CoAP protocol, focusing on the reverse proxy case. It describes how a HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to a HTTP response. Furthermore, it defines a template for URI mapping and provides a set of guidelines for HTTP to CoAP protocol translation and related proxy implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-http-mapping-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-http-mapping-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 6 08:22:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66A112D1B6; Wed, 6 Apr 2016 08:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RMlOtUmNeKT; Wed, 6 Apr 2016 08:22:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4994212D6A4; Wed, 6 Apr 2016 08:18:56 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1F8822AF75C54; Wed, 6 Apr 2016 15:18:51 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u36FIr3Z005121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 15:18:53 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u36FEjaW009836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 17:18:47 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 17:15:14 +0200 From: "Fossati, Thomas (Nokia - GB)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-http-mapping-09.txt Thread-Index: AQHRkBZq/lM7kD1fKkudMwEBWoLuGp98ujqA Date: Wed, 6 Apr 2016 15:15:14 +0000 Message-ID: References: <20160406150931.25001.51498.idtracker@ietfa.amsl.com> In-Reply-To: <20160406150931.25001.51498.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <09F9E6954C0EBA4E913B9DD5005B0B2E@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-http-mapping-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:22:55 -0000 We've just updated -09 with the clean up of the requirement language (last bit left of Klaus' original review). Will follow up on a separate email (or on Friday's f2f) with the final issue related to clarifying terminology around "reverse proxy". Cheers, t On 06/04/2016 12:09, "core on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Constrained RESTful Environments of the >IETF. > > Title : Guidelines for HTTP-CoAP Mapping Implementations > Authors : Angelo P. Castellani > Salvatore Loreto > Akbar Rahman > Thomas Fossati > Esko Dijk > Filename : draft-ietf-core-http-mapping-09.txt > Pages : 35 > Date : 2016-04-06 > >Abstract: > This document provides reference information for implementing a proxy > that performs translation between the HTTP protocol and the CoAP > protocol, focusing on the reverse proxy case. It describes how a > HTTP request is mapped to a CoAP request and how a CoAP response is > mapped back to a HTTP response. Furthermore, it defines a template > for URI mapping and provides a set of guidelines for HTTP to CoAP > protocol translation and related proxy implementations. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-core-http-mapping/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-core-http-mapping-09 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-http-mapping-09 > > >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 > From nobody Wed Apr 6 10:30:54 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D69B12D6D9 for ; Wed, 6 Apr 2016 10:30:52 -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, WEIRD_PORT=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 VDhIgAIAqJB3 for ; Wed, 6 Apr 2016 10:30:48 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BA612D6E4 for ; Wed, 6 Apr 2016 10:30:48 -0700 (PDT) Received: from mfilter46-d.gandi.net (mfilter46-d.gandi.net [217.70.178.177]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id CDEA2A80C2; Wed, 6 Apr 2016 19:30:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter46-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter46-d.gandi.net (mfilter46-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id nfHCB7reS6Am; Wed, 6 Apr 2016 19:30:44 +0200 (CEST) X-Originating-IP: 31.133.154.74 Received: from dhcp-9a4a.meeting.ietf.org (dhcp-9a4a.meeting.ietf.org [31.133.154.74]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E6A6FA80C8; Wed, 6 Apr 2016 19:30:43 +0200 (CEST) Message-ID: <570547C0.8080803@tzi.org> Date: Wed, 06 Apr 2016 14:30:40 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Summary of first meeting at IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:30:52 -0000 Here is my summary of what we did on Tuesday. Fixes/additions welcome; details are in the draft minutes at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core On Tuesday: * Andrew indicated that he plans to step down as a WG chair and that the ADs are looking for a replacement. * As periodically, the AD is changing; this time from a graybeard (Barry) to a blackbeard (Alexey). * The chairs apologize for the infrequently updated milestones; fixing them is up next. * draft-ietf-core-block–19 is in IESG Evaluation, telechat date is 2016–04–21. * heads-up for new individual drafts: draft-kivinen-802-15-ie and draft-bormann-6lo-coap-802-15-ie. * CoAP over TCP received extensive discussion. Results (all to be confirmed on the mailing list): * #396: We revert the decision in Yokohama and go with alternative L3. Procedurally, the pain of this reversal is balanced by the reduced pain of not having to convince OCF to change their specification. Technically, L3 is more open to evolving ideas about message sizes. In any case, there is no intent to modify or revoke section 4.6 of RFC 7252 at this time. * We will need to examine the various proposals to add signaling to the TCP connection (settings, ping/pong, release/abort). Signaling messages (7.xx) is one possible mechanism for doing that. * #387 (ALPN): We really need to make a decision here. * Websockets: For merging the websockets draft into the TCP/TLS WG document (with the websockets specific parts going to an appendix), the authors of both drafts will discuss the merge. * Multi-hop Security: Initial discussion of draft-hartke-core-e2e-security-reqs. * It is more well-defined what is being protected in a request-response that spans a proxy than with a pub-sub broker. * The current set of scenarios does not include the case that security services are being performed by the intermediary. Many such scenarios are conceivable; which ones have serious use cases? * Multicast (or, more generally, group communication) is not yet being considered. * Data Formats: WG to adopt SenML (to be confirmed on the mailing list). After a bit of Brownian motion, the WG is now happy with the way the data is formatted in -06 (base record with data, zero or more records with more data). The addition of links in the data is to be done by registering a senml label in core-links-json ("reversing the arrow of dependency"). Friday meeting upcoming. Grüße, Carsten From nobody Wed Apr 6 10:42:57 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0E12D723 for ; Wed, 6 Apr 2016 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 r4ljXSRbov7W for ; Wed, 6 Apr 2016 10:42:55 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EB012D6CA for ; Wed, 6 Apr 2016 10:42:36 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:f9e4:5178:13f5:2e53]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id DE9D3A80E1; Wed, 6 Apr 2016 19:42:33 +0200 (CEST) Message-ID: <57054A86.7050702@tzi.org> Date: Wed, 06 Apr 2016 14:42:30 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_WG_adoption_of?= =?utf-8?q?_draft-jennings-core-senml-06?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:42:56 -0000 As discussed in the previous message, the in-room consensus in Buenos Aires was to adopt draft-jennings-core-senml-06 as a CoRE WG draft. This is a one-week call for confirmation of that decision. Specifically, if you have an objection to this decision, please speak up on the mailing list by 2016-04-13. Grüße, Carsten From nobody Wed Apr 6 10:45:33 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C212D6EF for ; Wed, 6 Apr 2016 10:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 XXYktev9nkk1 for ; Wed, 6 Apr 2016 10:45:31 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C5912D1DF for ; Wed, 6 Apr 2016 10:45:31 -0700 (PDT) Received: from dhcp-9a4a.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:f9e4:5178:13f5:2e53]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E11BF1720CE; Wed, 6 Apr 2016 19:45:28 +0200 (CEST) Message-ID: <57054B35.50700@tzi.org> Date: Wed, 06 Apr 2016 14:45:25 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_CoAP_over_TCP/?= =?utf-8?q?TLS_=23396=3A_Revert_L1_selection=2C_select_L3?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:45:33 -0000 As discussed in a previous message, the in-room consensus in Buenos Aires was to revert the decision we made in Yokohama to go for alternative L1, and to instead select alternative L3. This is a one-week call for confirmation of that decision. Specifically, if you have an objection to this decision, please speak up on the mailing list by 2016-04-13. Grüße, Carsten From nobody Wed Apr 6 11:09:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F69C12D724 for ; Wed, 6 Apr 2016 11:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XssQMW1OZRbP for ; Wed, 6 Apr 2016 11:09:26 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6D0AE12D746 for ; Wed, 6 Apr 2016 11:09:09 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2774F26A7B5FE; Wed, 6 Apr 2016 18:09:04 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u36I962H005247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 18:09:07 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u36I95gM014640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 20:09:06 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 20:09:05 +0200 From: "Fossati, Thomas (Nokia - GB)" To: EXT Carles Gomez Montenegro , "EXT OSCAR GONZALEZ DE DIOS" Thread-Topic: [core] CoAP for high throughput applications Thread-Index: AQHRjr76eON/nMwwHUq4G5ODCqR3Gp96QgsA///UMQCAAoCGAIAAVrgA Date: Wed, 6 Apr 2016 18:09:05 +0000 Message-ID: References: <5702E93E.3030005@tzi.org> <54c26e6d388f0ea0564417ffc87a4091.squirrel@webmail.entel.upc.edu> In-Reply-To: <54c26e6d388f0ea0564417ffc87a4091.squirrel@webmail.entel.upc.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ilker.demirkol@entel.upc.edu" , "august.betzler@googlemail.com" , "core@ietf.org" Subject: Re: [core] CoAP for high throughput applications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:09:28 -0000 Hi Carles, Very interesting stuff, and thanks for the pointers. I'll try to put together Californium+CoCoA and Oscar's keyserver (https://github.com/mami-project/KeyServer) to see what happens :-) Cheers, t On 06/04/2016 06:58, "EXT Carles Gomez Montenegro" wrote: >Hi Thomas, > >>>> Now, a single LURK box could have to handle lots of these requests, >>>> potentially in thousands per second, whereas CoAP's default congestion >>>> control algorithm parameters [3] are, by design, way too conservative >>>> to >>>> be suitable for high-throughput use cases. >>> >>>That would be an interesting application for CoCoA... >> >> Is CoCoA available if I'd want to test it? > >Here you may find the Californium implementation including CoCoA: >https://github.com/eclipse/californium > >As Matthias said, the implementation including CoCoA is not actually >optimized for dealing with thousands of requests. However, CoCoA is >adaptive and, if network conditions allow it, the algorithm may behave >more aggressively than default CoAP's congestion control (while still >being safe). > >In the experiments we have done so far, we have dealt with up to hundreds >of requests per second (outperforming default CoAP and also >state-of-the-art alternative approaches designed for TCP), since the >limitation in our scenarios was the network/channel capacity (e.g. [1, >2]). > >It would be very interesting to see what happens in a scenario such as the >one you describe, where the limitation might not be the network >throughput. By the way, feedback on CoCoA would be very much welcome! > >Thanks, > >Carles > >[1] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoAP congestion >control for the Internet of Things", IEEE Communications Magazine >(In press). >https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control >_for_the_Internet_of_Things > >[2] A. Betzler, C. Gomez, I. Demirkol, J. Paradells, "CoCoA+: an advanced >congestion control mechanism for CoAP", Ad-hoc Networks journal, 2015. >http://www.sciencedirect.com/science/article/pii/S1570870515000888 From nobody Thu Apr 7 15:21:38 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318A412D118 for ; Thu, 7 Apr 2016 15:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrCN4a5A7UeS for ; Thu, 7 Apr 2016 15:21:34 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id 9787012D6FA for ; Thu, 7 Apr 2016 15:21:33 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6E24811533D_706DD6BB for ; Thu, 7 Apr 2016 22:21:31 +0000 (GMT) Received: from EXHUB01.org.aalto.fi (exhub01.org.aalto.fi [130.233.222.118]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 34B45115329_706DD6BF for ; Thu, 7 Apr 2016 22:21:31 +0000 (GMT) Received: from EXMDB01.org.aalto.fi ([169.254.2.240]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi id 14.03.0294.000; Fri, 8 Apr 2016 01:21:31 +0300 From: Aura Tuomas To: "core@ietf.org" Thread-Topic: About freshness and order of information in CoAP End-To-End Security Thread-Index: AdGRG8k6gBiuCzpESD6Xf3MZeAMeDA== Date: Thu, 7 Apr 2016 22:21:30 +0000 Message-ID: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.153.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [core] About freshness and order of information in CoAP End-To-End Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:21:37 -0000 Reading "draft-hartke-core-e2e-security-reqs-00", I started to wonder about= the freshness and reordering of sensor data and actuation confirmation. Th= e examples in section "3.1. One Request - One Response" seem quite simple = compared to potential application requirements.=20 https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#section-= 3.1=20 Example: Alarm status retrieval * There are many kinds of freshness: Sometimes you just want to avoid repla= ys, e.g. for counting events. Sometimes reordering of data is not allowed, = e.g. if you want the latest sensor status. Sometimes the data should come c= ausally after another event, e.g. in nonce-based freshness mechanisms that = bind the sensor data causally to a specific local clock interval at the rec= eiver. Sometimes the data needs to be recent by the wall clock time, e.g. i= f you have loosely synchronized clocks.=20 * In the alarm status example, it may not be necessary or sufficient for th= e status data to be "current". In fact, I don't think you ever need to link= the answer to the individual alarm status request. Sometimes it is ok to h= ave "recent" status information, in which case caching the at the proxy for= a short period is ok. Sometimes you may not want to miss alarms that were = raised and then dismissed, in which case the current status is not sufficie= nt but you need the full history.=20 Example: Actuation confirmation * Some actuation may have unique identity, e.g. admit animal number 12345 t= hrough the turnstile, and need to be confirmed individually. However, that = is not necessarily the case. Some actuation is cumulative, e.g. admit one p= erson though turnstile. Some actions are idempotent, e.g. close the door, a= nd one confirmation may be sufficient.=20 * Some actuations need to be strictly ordered, e.g. open and close the door= . Some can be reordered, e.g. close door A and close door B. This could pos= sibly be discussed in terms of causal order (the vector clocks mentioned in= the ACE WG list) and how much of that order needs to be preserved in the a= ctuation and in confirmations.=20 Perhaps some of the above comments are beside the point of the draft, but i= t looks to me that the concepts of freshness and ordering in object or mult= i-hop security are more difficult to define and address than in secure end-= to-end connections where data on the wire is linearly ordered in each direc= tion. Tuomas From nobody Fri Apr 8 00:37:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5212D146 for ; Fri, 8 Apr 2016 00:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtZm54_LYrIV for ; Fri, 8 Apr 2016 00:37:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7777112D11F for ; Fri, 8 Apr 2016 00:37:26 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-fe-57075fb4ae17 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.39.16394.4BF57075; Fri, 8 Apr 2016 09:37:24 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 09:37:23 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Aura Tuomas , "core@ietf.org" Thread-Topic: [core] About freshness and order of information in CoAP End-To-End Security Thread-Index: AQHRkWl9O78ERTYIGE68jZYY6505zA== Date: Fri, 8 Apr 2016 07:37:23 +0000 Message-ID: References: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> In-Reply-To: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <48D2B8979108104A9795CBC1222D0A6C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7nO6WePZwg4VH5S32vV3PbPFm4kZ2 ByaP468Xs3osWfKTKYApissmJTUnsyy1SN8ugSvj16UXjAUtGhXXnlxmb2BsUO9i5OSQEDCR WPjmKhOELSZx4d56ti5GLg4hgSOMEsdWr2OBcBYzSsy8cp0FpIpNwEXiQcMjsA4RAXeJzfsX MIPYwgJREh9fPWODiEdLvH12hxnC1pOYtvQxWD2LgIrEr6m/wObwClhITNt0ixXEFhLwlni9 eB47iM0p4CNxf+pfsBpGoIu+n1oD1sssIC5x68l8qEsFJJbsOc8MYYtKvHz8D2yOKNCuHecg bAkBJYkV2y8xdjFyAPVqSqzfpQ8xxlpi1eRjUCMVJaZ0P2SHOEdQ4uTMJywTGMVnIdk2C6F7 FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMNoObvmtuoPx8hvHQ4wC HIxKPLwLBNjDhVgTy4orcw8xSnAwK4nw/ooFCvGmJFZWpRblxxeV5qQWH2KU5mBREufNjvwX JiSQnliSmp2aWpBaBJNl4uCUamC0ml0stPGHiODhmQUHl/k9Y1689N1XiwkSJ7ie2gl4nz/8 44irEfPFSx5/OY+zOWy7+mZ546Zn6SGszWIfOFfcWurmUcqWknRw5scvG1/9mn920j6ntX0z VHh/V75e+EDc/Z6W1H+NZjvWyOBJD5Zbc2+Jak4X1BV7+erFt2ifJ7J2yss7LMTSlFiKMxIN tZiLihMBI7ukt7ICAAA= Archived-At: Subject: Re: [core] About freshness and order of information in CoAP End-To-End Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 07:37:29 -0000 SGkgVGhvbWFzLA0KDQpUaGFua3MgZm9yIGNvbW1lbnRzLCBpbmxpbmUNCg0KT24gMjAxNi0wNC0w NyAxOToyMSwgImNvcmUgb24gYmVoYWxmIG9mIEF1cmEgVHVvbWFzIg0KPGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgdHVvbWFzLmF1cmFAYWFsdG8uZmk+IHdyb3RlOg0KDQo+UmVh ZGluZyAiZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMtMDAiLCBJIHN0YXJ0ZWQg dG8gd29uZGVyDQo+YWJvdXQgdGhlIGZyZXNobmVzcyBhbmQgcmVvcmRlcmluZyBvZiBzZW5zb3Ig ZGF0YSBhbmQgYWN0dWF0aW9uDQo+Y29uZmlybWF0aW9uLiBUaGUgZXhhbXBsZXMgaW4gc2VjdGlv biAiMy4xLiAgT25lIFJlcXVlc3QgLSBPbmUgUmVzcG9uc2UiDQo+c2VlbSBxdWl0ZSBzaW1wbGUg Y29tcGFyZWQgdG8gcG90ZW50aWFsIGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cy4NCj4NCj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJl cXMtMDAjc2VjdGlvbg0KPi0zLjEgDQo+DQo+RXhhbXBsZTogQWxhcm0gc3RhdHVzIHJldHJpZXZh bA0KPg0KPiogVGhlcmUgYXJlIG1hbnkga2luZHMgb2YgZnJlc2huZXNzOiBTb21ldGltZXMgeW91 IGp1c3Qgd2FudCB0byBhdm9pZA0KPnJlcGxheXMsIGUuZy4gZm9yIGNvdW50aW5nIGV2ZW50cy4g U29tZXRpbWVzIHJlb3JkZXJpbmcgb2YgZGF0YSBpcyBub3QNCj5hbGxvd2VkLCBlLmcuIGlmIHlv dSB3YW50IHRoZSBsYXRlc3Qgc2Vuc29yIHN0YXR1cy4gU29tZXRpbWVzIHRoZSBkYXRhDQo+c2hv dWxkIGNvbWUgY2F1c2FsbHkgYWZ0ZXIgYW5vdGhlciBldmVudCwgZS5nLiBpbiBub25jZS1iYXNl ZCBmcmVzaG5lc3MNCj5tZWNoYW5pc21zIHRoYXQgYmluZCB0aGUgc2Vuc29yIGRhdGEgY2F1c2Fs bHkgdG8gYSBzcGVjaWZpYyBsb2NhbCBjbG9jaw0KPmludGVydmFsIGF0IHRoZSByZWNlaXZlci4g U29tZXRpbWVzIHRoZSBkYXRhIG5lZWRzIHRvIGJlIHJlY2VudCBieSB0aGUNCj53YWxsIGNsb2Nr IHRpbWUsIGUuZy4gaWYgeW91IGhhdmUgbG9vc2VseSBzeW5jaHJvbml6ZWQgY2xvY2tzLg0KPg0K PiogSW4gdGhlIGFsYXJtIHN0YXR1cyBleGFtcGxlLCBpdCBtYXkgbm90IGJlIG5lY2Vzc2FyeSBv ciBzdWZmaWNpZW50IGZvcg0KPnRoZSBzdGF0dXMgZGF0YSB0byBiZSAiY3VycmVudCIuIEluIGZh Y3QsIEkgZG9uJ3QgdGhpbmsgeW91IGV2ZXIgbmVlZCB0bw0KPmxpbmsgdGhlIGFuc3dlciB0byB0 aGUgaW5kaXZpZHVhbCBhbGFybSBzdGF0dXMgcmVxdWVzdC4gU29tZXRpbWVzIGl0IGlzDQo+b2sg dG8gaGF2ZSAicmVjZW50IiBzdGF0dXMgaW5mb3JtYXRpb24sIGluIHdoaWNoIGNhc2UgY2FjaGlu ZyB0aGUgYXQgdGhlDQo+cHJveHkgZm9yIGEgc2hvcnQgcGVyaW9kIGlzIG9rLiBTb21ldGltZXMg eW91IG1heSBub3Qgd2FudCB0byBtaXNzIGFsYXJtcw0KPnRoYXQgd2VyZSByYWlzZWQgYW5kIHRo ZW4gZGlzbWlzc2VkLCBpbiB3aGljaCBjYXNlIHRoZSBjdXJyZW50IHN0YXR1cyBpcw0KPm5vdCBz dWZmaWNpZW50IGJ1dCB5b3UgbmVlZCB0aGUgZnVsbCBoaXN0b3J5Lg0KDQpJdCBpcyB0cnVlIHRo YXQgZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBoYXZlIGRpZmZlcmVudCB0eXBlcyBvZiBmcmVzaG5l c3MNCnJlcXVpcmVtZW50cy4gSXQgaXMgYWxzbyB0cnVlIHRoYXQgZm9yIGRldmljZXMgdGhhdCBj YW4gbWFpbnRhaW4NCnRpbWUgc3luY2hyb25pc2F0aW9uIGl0IG1heSBiZSBzdWZmaWNpZW50IHRv IHZlcmlmeSBhIOKAnHJlY2VudOKAnQ0Kc3RhdGUgKGFsdGhvdWdoIHRoZXJlIGlzIGFsd2F5cyBh IGNvbmNlcm4gdGhhdCB0aGUgY2xvY2tzIG1heSkNCg0KQXMgeW91IG5vdGVkLCB3aXRoIHF1aWNr bHkgdHJhbnNpdGlvbmluZyBzdGF0ZXMgc3RhdHVzIHJlcXVlc3RzIHByb3ZpZGVzDQp2ZXJ5IGxp bWl0ZWQgaW5mb3JtYXRpb24sIGJldHRlciBtZWFzdXJlIGEgZGlmZmVyZW50IHN0YXR1cyBwYXJh bWV0ZXIsDQplLmcuIHdob3NlIHZhbHVlIHJlZmxlY3RzIGFuIGFsYXJtIHRoYXQgbmVlZHMgdG8g YmUgcmVzZXQgYnkgYXV0aG9yaXNlZA0KcGVyc29ubmVsLiBBbmQgaW4gdGhhdCBjYXNlLCB3aGVu IHRpbWUgc3luY2hyb25pc2F0aW9uIGNhbuKAmXQgYmUNCmd1YXJhbnRlZWQsIGEgY2hhbGxlbmdl LXJlc3BvbnNlIHByb3RvY29sIHByb3ZpZGVzIG9uZSB3YXkgdG8gZ2V0IHNvbWUNCmNlcnRhaW50 eSBvZiBhIHJlbGV2YW50IHN0YXR1cyBwYXJhbWV0ZXIuDQoNCj4NCj5FeGFtcGxlOiBBY3R1YXRp b24gY29uZmlybWF0aW9uDQo+DQo+KiBTb21lIGFjdHVhdGlvbiBtYXkgaGF2ZSB1bmlxdWUgaWRl bnRpdHksIGUuZy4gYWRtaXQgYW5pbWFsIG51bWJlciAxMjM0NQ0KPnRocm91Z2ggdGhlIHR1cm5z dGlsZSwgYW5kIG5lZWQgdG8gYmUgY29uZmlybWVkIGluZGl2aWR1YWxseS4gSG93ZXZlciwNCj50 aGF0IGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgY2FzZS4gU29tZSBhY3R1YXRpb24gaXMgY3VtdWxh dGl2ZSwgZS5nLg0KPmFkbWl0IG9uZSBwZXJzb24gdGhvdWdoIHR1cm5zdGlsZS4gU29tZSBhY3Rp b25zIGFyZSBpZGVtcG90ZW50LCBlLmcuDQo+Y2xvc2UgdGhlIGRvb3IsIGFuZCBvbmUgY29uZmly bWF0aW9uIG1heSBiZSBzdWZmaWNpZW50Lg0KPg0KPiogU29tZSBhY3R1YXRpb25zIG5lZWQgdG8g YmUgc3RyaWN0bHkgb3JkZXJlZCwgZS5nLiBvcGVuIGFuZCBjbG9zZSB0aGUNCj5kb29yLiBTb21l IGNhbiBiZSByZW9yZGVyZWQsIGUuZy4gY2xvc2UgZG9vciBBIGFuZCBjbG9zZSBkb29yIEIuIFRo aXMNCj5jb3VsZCBwb3NzaWJseSBiZSBkaXNjdXNzZWQgaW4gdGVybXMgb2YgY2F1c2FsIG9yZGVy ICh0aGUgdmVjdG9yIGNsb2Nrcw0KPm1lbnRpb25lZCBpbiB0aGUgQUNFIFdHIGxpc3QpIGFuZCBo b3cgbXVjaCBvZiB0aGF0IG9yZGVyIG5lZWRzIHRvIGJlDQo+cHJlc2VydmVkIGluIHRoZSBhY3R1 YXRpb24gYW5kIGluIGNvbmZpcm1hdGlvbnMuDQoNCkFsc28gdmVyeSBpbnRlcmVzdGluZyBleGFt cGxlcyBpbGx1c3RyYXRpbmcgdGhlIHdpZGUgdmFyaWV0eSBvZg0KYXBwbGljYXRpb24gc2V0dGlu Z3MuIEFnYWluLCBkZXBlbmRpbmcgb24gdXNlIGNhc2UgdGhlDQoNCj4gDQo+DQo+UGVyaGFwcyBz b21lIG9mIHRoZSBhYm92ZSBjb21tZW50cyBhcmUgYmVzaWRlIHRoZSBwb2ludCBvZiB0aGUgZHJh ZnQsIGJ1dA0KPml0IGxvb2tzIHRvIG1lIHRoYXQgdGhlIGNvbmNlcHRzIG9mIGZyZXNobmVzcyBh bmQgb3JkZXJpbmcgaW4gb2JqZWN0IG9yDQo+bXVsdGktaG9wIHNlY3VyaXR5IGFyZSBtb3JlIGRp ZmZpY3VsdCB0byBkZWZpbmUgYW5kIGFkZHJlc3MgdGhhbiBpbg0KPnNlY3VyZSBlbmQtdG8tZW5k IGNvbm5lY3Rpb25zIHdoZXJlIGRhdGEgb24gdGhlIHdpcmUgaXMgbGluZWFybHkgb3JkZXJlZA0K PmluIGVhY2ggZGlyZWN0aW9uLg0KDQpZZXMgdGhlcmUgYXJlIGNlcnRhaW5seSBjaGFsbGVuZ2Vz IGhlcmUuIElzIHlvdXIgcHJvcG9zYWwgdGhhdCB3ZSBwcm92aWRlDQptb3JlIGRldGFpbHMgdG8g dGhlIGV4YW1wbGVzIHdoZXJlIHRoZSBzY2VuYXJpb3MgYXJlIGFwcGxpY2FibGU/DQoNCkfDtnJh bg0KDQo+DQo+VHVvbWFzDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5jb3JlIG1haWxpbmcgbGlzdA0KPmNvcmVAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K From nobody Fri Apr 8 01:28:23 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708DE12D571 for ; Fri, 8 Apr 2016 01:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 uHwTcZhMRh9T for ; Fri, 8 Apr 2016 01:28:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076AC12D555 for ; Fri, 8 Apr 2016 01:28:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-4b-57076b9f97d3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.A6.23401.F9B67075; Fri, 8 Apr 2016 10:28:16 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.117]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 10:27:27 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Aura Tuomas , "core@ietf.org" Thread-Topic: [core] About freshness and order of information in CoAP End-To-End Security Thread-Index: AQHRkWl9O78ERTYIGE68jZYY6505zJ9/alEA Date: Fri, 8 Apr 2016 08:27:27 +0000 Message-ID: References: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7uu6CbPZwg4XvOSz2vV3PbPFm4kZ2 ByaP468Xs3osWfKTKYApissmJTUnsyy1SN8ugSvj3uS3rAVLTCqWrrjN3MD4w6iLkZNDQsBE 4vDhn8wQtpjEhXvr2boYuTiEBI4wSqze9BLKWcwo8XTbCrAqNgEXiQcNj5hAbBEBd4nN+xeA xYUFoiQ+vnrGBhGPlnj77A4zhG0kcevrA1YQm0VARaJr4VEwm1fAQmLv1lPsILaQQJXEq9bH QPUcHJwClhI3+4NBwoxAB30/tQZsFbOAuMStJ/OZIA4VkFiy5zzU0aISLx//AxspKqAnseMc hC0hoCSx9vB2FpCRzAKaEut36UOMsZbYtxDiSmYBRYkp3Q/ZIa4RlDg58wnLBEbxWUi2zULo noWkexaS7llIuhcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy1g1t+W+1gPPjc8RCj AAejEg/vAgH2cCHWxLLiytxDjBIczEoivCnpQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8OZH/ woQE0hNLUrNTUwtSi2CyTBycUg2MS5hsu2Yopi9nq+22fqiuVq13JG1KtaXhSvk2L5ZPlTv4 jrz6sNh6CtcRm/18m1g617W97vfRXG32MeZb1L6bG99rf3P8wSY/of3MHcszlSnnpQ8+bpR0 311z1D7wTo1YTODJuQyO9jPW717kbtOnWRXdWdWv+bmb7aKL4exnOlqf3n4uyJZWYinOSDTU Yi4qTgQAxmE/KLECAAA= Archived-At: Subject: Re: [core] About freshness and order of information in CoAP End-To-End Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:28:21 -0000 SGkgYWdhaW4gVHVvbWFzLA0KDQoNCkl0IHNlZW1zIEkgbWlzc2VkIHRvIGNvbXBsZXRlIHNvbWUg c2VudGVuY2VzLiBIZXJlIGFyZSB0aGUgbWlzc2luZyBnYXBzOg0KDQpBYm91dCB0aW1lIGFzIGZy ZXNobmVzczogdGhlcmUgaXMgYWx3YXlzIHRoZSBjb25jZXJuIHRoYXQgdGhlIGRldmljZXMNCnNo b3VsZCBiZSBzeW5jaHJvbmlzZWQgYnV0IGZvciBzb21lIHJlYXNvbiBhcmUgbm90LCB1bmxlc3Mg eW91IGNvbnN0YW50bHkNCnN5bmNocm9uaXNlLg0KDQpBYm91dCBhY3R1YXRvciBhcHBsaWNhdGlv bnM6IGFsc28gaGVyZSB0aGVyZSBhcmUgZGlmZmVyZW50IHdheXMgZm9yIGENCnNlY3VyaXR5IHNv bHV0aW9uIHRvIHN1cHBvcnQgdGhlIGNsaWVudCB0byBpbmZlciBzb21lIGFzcGVjdCBvZiBmcmVz aG5lc3M6DQppbnRlZ3JpdHkgcHJvdGVjdGlvbiBvZiBzb21lIHRpbWUgcGFyYW1ldGVyLCBhbmQg Y2hhbGxlbmdlLXJlc3BvbnNlIGJhc2VkDQphcmUgYm90aCB1c2VmdWwgaW4gZGlmZmVyZW50IHNl dHRpbmdzLg0KDQpBcyBJIHNlZSB0aGUgZTJlIHNlY3VyaXR5IHdvcmsgd2Ugc2hvdWxkIGRlc2Ny aWJlIGEgc2V0IG9mIHJlbGV2YW50DQpzY2VuYXJpb3MgdGhhdCBpbGx1c3RyYXRlcyB0aGUgYmFz aWMgY29uc3RydWN0cyBuZWVkZWQsIGRldmVsb3AgdGhvc2UgYW5kDQp0aGVuIGFsbG93IGFwcGxp Y2F0aW9ucyB0byBidWlsZCBzb2x1dGlvbnMgdXNpbmcgdGhlbS4gQW5kIGFzIHlvdXINCmV4YW1w bGVzIGlsbHVzdHJhdGUsIHRoZSBsYXR0ZXIgbWF5IGJlIGEgY2hhbGxlbmdlLCBidXQgaXMgSU1I TyBvdXQgb2YNCnNjb3BlIGZvciB0aGlzIHdvcmsuDQoNCkRvIHlvdSBzZWUgYW55IHNwZWNpZmlj IHJlcXVpcmVtZW50cywgb3IgcmVxdWlyZW1lbnQgc2V0cyB0aGF0IGFyZSBtaXNzaW5nDQppbiB0 aGlzIHJlc3BlY3Q/DQoNCkFnYWluLCB0aGFua3MgZm9yIGdvb2QgY29tbWVudHMuDQoNCkfDtnJh bg0KDQoNCk9uIDIwMTYtMDQtMDggMDQ6MzcsICJHw7ZyYW4gU2VsYW5kZXIiIDxnb3Jhbi5zZWxh bmRlckBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+SGkgVGhvbWFzLA0KPg0KPlRoYW5rcyBmb3Ig Y29tbWVudHMsIGlubGluZQ0KPg0KPk9uIDIwMTYtMDQtMDcgMTk6MjEsICJjb3JlIG9uIGJlaGFs ZiBvZiBBdXJhIFR1b21hcyINCj48Y29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0 dW9tYXMuYXVyYUBhYWx0by5maT4gd3JvdGU6DQo+DQo+PlJlYWRpbmcgImRyYWZ0LWhhcnRrZS1j b3JlLWUyZS1zZWN1cml0eS1yZXFzLTAwIiwgSSBzdGFydGVkIHRvIHdvbmRlcg0KPj5hYm91dCB0 aGUgZnJlc2huZXNzIGFuZCByZW9yZGVyaW5nIG9mIHNlbnNvciBkYXRhIGFuZCBhY3R1YXRpb24N Cj4+Y29uZmlybWF0aW9uLiBUaGUgZXhhbXBsZXMgaW4gc2VjdGlvbiAiMy4xLiAgT25lIFJlcXVl c3QgLSBPbmUgUmVzcG9uc2UiDQo+PnNlZW0gcXVpdGUgc2ltcGxlIGNvbXBhcmVkIHRvIHBvdGVu dGlhbCBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMuDQo+Pg0KPj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMtMDAjc2VjdGlvDQo+ Pm4NCj4+LTMuMSANCj4+DQo+PkV4YW1wbGU6IEFsYXJtIHN0YXR1cyByZXRyaWV2YWwNCj4+DQo+ PiogVGhlcmUgYXJlIG1hbnkga2luZHMgb2YgZnJlc2huZXNzOiBTb21ldGltZXMgeW91IGp1c3Qg d2FudCB0byBhdm9pZA0KPj5yZXBsYXlzLCBlLmcuIGZvciBjb3VudGluZyBldmVudHMuIFNvbWV0 aW1lcyByZW9yZGVyaW5nIG9mIGRhdGEgaXMgbm90DQo+PmFsbG93ZWQsIGUuZy4gaWYgeW91IHdh bnQgdGhlIGxhdGVzdCBzZW5zb3Igc3RhdHVzLiBTb21ldGltZXMgdGhlIGRhdGENCj4+c2hvdWxk IGNvbWUgY2F1c2FsbHkgYWZ0ZXIgYW5vdGhlciBldmVudCwgZS5nLiBpbiBub25jZS1iYXNlZCBm cmVzaG5lc3MNCj4+bWVjaGFuaXNtcyB0aGF0IGJpbmQgdGhlIHNlbnNvciBkYXRhIGNhdXNhbGx5 IHRvIGEgc3BlY2lmaWMgbG9jYWwgY2xvY2sNCj4+aW50ZXJ2YWwgYXQgdGhlIHJlY2VpdmVyLiBT b21ldGltZXMgdGhlIGRhdGEgbmVlZHMgdG8gYmUgcmVjZW50IGJ5IHRoZQ0KPj53YWxsIGNsb2Nr IHRpbWUsIGUuZy4gaWYgeW91IGhhdmUgbG9vc2VseSBzeW5jaHJvbml6ZWQgY2xvY2tzLg0KPj4N Cj4+KiBJbiB0aGUgYWxhcm0gc3RhdHVzIGV4YW1wbGUsIGl0IG1heSBub3QgYmUgbmVjZXNzYXJ5 IG9yIHN1ZmZpY2llbnQgZm9yDQo+PnRoZSBzdGF0dXMgZGF0YSB0byBiZSAiY3VycmVudCIuIElu IGZhY3QsIEkgZG9uJ3QgdGhpbmsgeW91IGV2ZXIgbmVlZCB0bw0KPj5saW5rIHRoZSBhbnN3ZXIg dG8gdGhlIGluZGl2aWR1YWwgYWxhcm0gc3RhdHVzIHJlcXVlc3QuIFNvbWV0aW1lcyBpdCBpcw0K Pj5vayB0byBoYXZlICJyZWNlbnQiIHN0YXR1cyBpbmZvcm1hdGlvbiwgaW4gd2hpY2ggY2FzZSBj YWNoaW5nIHRoZSBhdCB0aGUNCj4+cHJveHkgZm9yIGEgc2hvcnQgcGVyaW9kIGlzIG9rLiBTb21l dGltZXMgeW91IG1heSBub3Qgd2FudCB0byBtaXNzIGFsYXJtcw0KPj50aGF0IHdlcmUgcmFpc2Vk IGFuZCB0aGVuIGRpc21pc3NlZCwgaW4gd2hpY2ggY2FzZSB0aGUgY3VycmVudCBzdGF0dXMgaXMN Cj4+bm90IHN1ZmZpY2llbnQgYnV0IHlvdSBuZWVkIHRoZSBmdWxsIGhpc3RvcnkuDQo+DQo+SXQg aXMgdHJ1ZSB0aGF0IGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgaGF2ZSBkaWZmZXJlbnQgdHlwZXMg b2YgZnJlc2huZXNzDQo+cmVxdWlyZW1lbnRzLiBJdCBpcyBhbHNvIHRydWUgdGhhdCBmb3IgZGV2 aWNlcyB0aGF0IGNhbiBtYWludGFpbg0KPnRpbWUgc3luY2hyb25pc2F0aW9uIGl0IG1heSBiZSBz dWZmaWNpZW50IHRvIHZlcmlmeSBhIOKAnHJlY2VudOKAnQ0KPnN0YXRlIChhbHRob3VnaCB0aGVy ZSBpcyBhbHdheXMgYSBjb25jZXJuIHRoYXQgdGhlIGNsb2NrcyBtYXkpDQo+DQo+QXMgeW91IG5v dGVkLCB3aXRoIHF1aWNrbHkgdHJhbnNpdGlvbmluZyBzdGF0ZXMgc3RhdHVzIHJlcXVlc3RzIHBy b3ZpZGVzDQo+dmVyeSBsaW1pdGVkIGluZm9ybWF0aW9uLCBiZXR0ZXIgbWVhc3VyZSBhIGRpZmZl cmVudCBzdGF0dXMgcGFyYW1ldGVyLA0KPmUuZy4gd2hvc2UgdmFsdWUgcmVmbGVjdHMgYW4gYWxh cm0gdGhhdCBuZWVkcyB0byBiZSByZXNldCBieSBhdXRob3Jpc2VkDQo+cGVyc29ubmVsLiBBbmQg aW4gdGhhdCBjYXNlLCB3aGVuIHRpbWUgc3luY2hyb25pc2F0aW9uIGNhbuKAmXQgYmUNCj5ndWFy YW50ZWVkLCBhIGNoYWxsZW5nZS1yZXNwb25zZSBwcm90b2NvbCBwcm92aWRlcyBvbmUgd2F5IHRv IGdldCBzb21lDQo+Y2VydGFpbnR5IG9mIGEgcmVsZXZhbnQgc3RhdHVzIHBhcmFtZXRlci4NCj4N Cj4+DQo+PkV4YW1wbGU6IEFjdHVhdGlvbiBjb25maXJtYXRpb24NCj4+DQo+PiogU29tZSBhY3R1 YXRpb24gbWF5IGhhdmUgdW5pcXVlIGlkZW50aXR5LCBlLmcuIGFkbWl0IGFuaW1hbCBudW1iZXIg MTIzNDUNCj4+dGhyb3VnaCB0aGUgdHVybnN0aWxlLCBhbmQgbmVlZCB0byBiZSBjb25maXJtZWQg aW5kaXZpZHVhbGx5LiBIb3dldmVyLA0KPj50aGF0IGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgY2Fz ZS4gU29tZSBhY3R1YXRpb24gaXMgY3VtdWxhdGl2ZSwgZS5nLg0KPj5hZG1pdCBvbmUgcGVyc29u IHRob3VnaCB0dXJuc3RpbGUuIFNvbWUgYWN0aW9ucyBhcmUgaWRlbXBvdGVudCwgZS5nLg0KPj5j bG9zZSB0aGUgZG9vciwgYW5kIG9uZSBjb25maXJtYXRpb24gbWF5IGJlIHN1ZmZpY2llbnQuDQo+ Pg0KPj4qIFNvbWUgYWN0dWF0aW9ucyBuZWVkIHRvIGJlIHN0cmljdGx5IG9yZGVyZWQsIGUuZy4g b3BlbiBhbmQgY2xvc2UgdGhlDQo+PmRvb3IuIFNvbWUgY2FuIGJlIHJlb3JkZXJlZCwgZS5nLiBj bG9zZSBkb29yIEEgYW5kIGNsb3NlIGRvb3IgQi4gVGhpcw0KPj5jb3VsZCBwb3NzaWJseSBiZSBk aXNjdXNzZWQgaW4gdGVybXMgb2YgY2F1c2FsIG9yZGVyICh0aGUgdmVjdG9yIGNsb2Nrcw0KPj5t ZW50aW9uZWQgaW4gdGhlIEFDRSBXRyBsaXN0KSBhbmQgaG93IG11Y2ggb2YgdGhhdCBvcmRlciBu ZWVkcyB0byBiZQ0KPj5wcmVzZXJ2ZWQgaW4gdGhlIGFjdHVhdGlvbiBhbmQgaW4gY29uZmlybWF0 aW9ucy4NCj4NCj5BbHNvIHZlcnkgaW50ZXJlc3RpbmcgZXhhbXBsZXMgaWxsdXN0cmF0aW5nIHRo ZSB3aWRlIHZhcmlldHkgb2YNCj5hcHBsaWNhdGlvbiBzZXR0aW5ncy4gQWdhaW4sIGRlcGVuZGlu ZyBvbiB1c2UgY2FzZSB0aGUNCj4NCj4+IA0KPj4NCj4+UGVyaGFwcyBzb21lIG9mIHRoZSBhYm92 ZSBjb21tZW50cyBhcmUgYmVzaWRlIHRoZSBwb2ludCBvZiB0aGUgZHJhZnQsIGJ1dA0KPj5pdCBs b29rcyB0byBtZSB0aGF0IHRoZSBjb25jZXB0cyBvZiBmcmVzaG5lc3MgYW5kIG9yZGVyaW5nIGlu IG9iamVjdCBvcg0KPj5tdWx0aS1ob3Agc2VjdXJpdHkgYXJlIG1vcmUgZGlmZmljdWx0IHRvIGRl ZmluZSBhbmQgYWRkcmVzcyB0aGFuIGluDQo+PnNlY3VyZSBlbmQtdG8tZW5kIGNvbm5lY3Rpb25z IHdoZXJlIGRhdGEgb24gdGhlIHdpcmUgaXMgbGluZWFybHkgb3JkZXJlZA0KPj5pbiBlYWNoIGRp cmVjdGlvbi4NCj4NCj5ZZXMgdGhlcmUgYXJlIGNlcnRhaW5seSBjaGFsbGVuZ2VzIGhlcmUuIElz IHlvdXIgcHJvcG9zYWwgdGhhdCB3ZSBwcm92aWRlDQo+bW9yZSBkZXRhaWxzIHRvIHRoZSBleGFt cGxlcyB3aGVyZSB0aGUgc2NlbmFyaW9zIGFyZSBhcHBsaWNhYmxlPw0KPg0KPkfDtnJhbg0KPg0K Pj4NCj4+VHVvbWFzDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj5jb3JlIG1haWxpbmcgbGlzdA0KPj5jb3JlQGlldGYub3JnDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPg0KDQo= From nobody Fri Apr 8 06:32:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1EA12D8BE for ; Fri, 8 Apr 2016 06:32:47 -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] 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 YdLbXhs8DZ-Z for ; Fri, 8 Apr 2016 06:32:40 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECB212D8C6 for ; Fri, 8 Apr 2016 06:32:40 -0700 (PDT) Received: from hebrews (dhcp-aae6.meeting.ietf.org [31.133.170.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 476092CA0C; Fri, 8 Apr 2016 06:32:39 -0700 (PDT) From: "Jim Schaad" To: "'Aura Tuomas'" , References: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> In-Reply-To: <7F9C975440487E49BBD35F4FB088ED74CFD21D9C@EXMDB01.org.aalto.fi> Date: Fri, 8 Apr 2016 10:32:35 -0300 Message-ID: <011801d1919b$1eb23950$5c16abf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEyvACqOi5gjLg9TxSTKxmfTrxfCqC9vT0w Content-Language: en-us Archived-At: Subject: Re: [core] About freshness and order of information in CoAP End-To-End Security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:32:47 -0000 When I look at this my first thought is that some of this is not a security issue but a content issue. How many of these same problems do you have if you do not have security as part of the scenario you are looking at. I don't know that security is necessarily the right place to be doing enforcement of freshness. It makes sense for it to deal with issues of security not issues of protocol. I.e. I think that freshness is quite possibly something that should be addressed in the payload and not in the security wrapper. Jim > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Aura Tuomas > Sent: Thursday, April 07, 2016 7:22 PM > To: core@ietf.org > Subject: [core] About freshness and order of information in CoAP End-To-End > Security > > Reading "draft-hartke-core-e2e-security-reqs-00", I started to wonder about the > freshness and reordering of sensor data and actuation confirmation. The > examples in section "3.1. One Request - One Response" seem quite simple > compared to potential application requirements. > > https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#section-3 .1 > > Example: Alarm status retrieval > > * There are many kinds of freshness: Sometimes you just want to avoid replays, > e.g. for counting events. Sometimes reordering of data is not allowed, e.g. if > you want the latest sensor status. Sometimes the data should come causally > after another event, e.g. in nonce-based freshness mechanisms that bind the > sensor data causally to a specific local clock interval at the receiver. Sometimes > the data needs to be recent by the wall clock time, e.g. if you have loosely > synchronized clocks. > > * In the alarm status example, it may not be necessary or sufficient for the > status data to be "current". In fact, I don't think you ever need to link the answer > to the individual alarm status request. Sometimes it is ok to have "recent" status > information, in which case caching the at the proxy for a short period is ok. > Sometimes you may not want to miss alarms that were raised and then > dismissed, in which case the current status is not sufficient but you need the full > history. > > Example: Actuation confirmation > > * Some actuation may have unique identity, e.g. admit animal number 12345 > through the turnstile, and need to be confirmed individually. However, that is > not necessarily the case. Some actuation is cumulative, e.g. admit one person > though turnstile. Some actions are idempotent, e.g. close the door, and one > confirmation may be sufficient. > > * Some actuations need to be strictly ordered, e.g. open and close the door. > Some can be reordered, e.g. close door A and close door B. This could possibly > be discussed in terms of causal order (the vector clocks mentioned in the ACE > WG list) and how much of that order needs to be preserved in the actuation and > in confirmations. > > Perhaps some of the above comments are beside the point of the draft, but it > looks to me that the concepts of freshness and ordering in object or multi-hop > security are more difficult to define and address than in secure end-to-end > connections where data on the wire is linearly ordered in each direction. > > Tuomas > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Apr 8 09:06:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8650812D573 for ; Fri, 8 Apr 2016 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-SG_140sTVZ for ; Fri, 8 Apr 2016 09:06:11 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD812D1CB for ; Fri, 8 Apr 2016 09:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1460131568; d=isode.com; s=selector; i=@isode.com; bh=RGxUPBS5AVBZqr4xMgr+y3y7KTJ7C4JP5M/QHw4uLg8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bzVyVhakfRewgvBakCZPD0sqsZtsni9UFyeckJDnAnf8oPPL2TQTfl6l3ix8POjBwIC3Sd TfBnnQkIhhZgdbqQqVjUTMAgsaFFCVOFDwAMC9/b9y7Y7fDCYvssjpMf8xTa2yiwrOEgZj f/NWRi3YpeBPZE7o0y6mgJ6kTB8Xdc4=; Received: from [31.133.176.254] (dhcp-b0fe.meeting.ietf.org [31.133.176.254]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 8 Apr 2016 17:06:07 +0100 From: Alexey Melnikov To: core@ietf.org Message-ID: <5707D6F8.40000@isode.com> Date: Fri, 8 Apr 2016 17:06:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020702090707060701080902" Archived-At: Subject: [core] Incoming AD review of draft-ietf-core-block-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:06:13 -0000 --------------020702090707060701080902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I am mostly happy with this document, but I have a few comments/questions: On page 11: Clients that want to retrieve all blocks of a resource SHOULD strive to do so without undue delay. This is not an interoperability issue and it would be impossible to verify compliance with it, unless you have a number that specifies what is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here. Just use lowercased "should" instead. Similarly, in 2.5: Clients SHOULD strive to send all blocks of a request without undue delay. (Similar text in 2.6) In 2.9.2: Should probably also mention that this response code is also used for mismatching content-format options In 2.10: A response with a Block1 Option in control usage with the M bit set invalidates cached responses for the target URI. Can you explain the reason for this? In 3.2: A stateless server that simply builds/updates the resource in place (statelessly) may indicate this by not setting the more bit in the response (Figure 8); in this case, the response codes are valid separately for each block being updated. What is the behaviour of both the client and the server if PUT on a particular block fails? Is this clear enough in the document? Other questions I have after reviewing the document. If I missed where they are answered, please point me out to existing text in the document or another RFC: Is there a special error for block size mismatch between multiple requests? As block2 is a critical option, how can a server know if a particular client supports this option? Thank you, Alexey --------------020702090707060701080902 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi,
I am mostly happy with this document, but I have a few comments/questions:

On page 11: 
   Clients that want to retrieve
   all blocks of a resource SHOULD strive to do so without undue delay.
This is not an interoperability issue and it would be impossible to verify compliance with it, unless you have a number that specifies what is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here. Just use lowercased "should" instead.

Similarly, in 2.5:

   Clients SHOULD strive to send all blocks of a
   request without undue delay.
(Similar text in 2.6)


In 2.9.2:

Should probably also mention that this response code is also used for =C2=A0mismatching content-format options

In 2.10:
   A response with a Block1 Option in control usage
   with the M bit set invalidates cached responses for the target URI.
Can you explain the reason for this?

In 3.2:

   A stateless server that simply builds/updates the resource in pla=
ce
   (statelessly) may indicate this by not setting the more bit in the
   response (Figure 8); in this case, the response codes are valid
   separately for each block being updated.
What is the behaviour of both the client and the server if PUT on a particular block fails? Is this clear enough in the document?

Other questions I have after reviewing the document. If I missed where they are answered, please point me out to existing text in the document or another RFC:

Is there a special error for block size mismatch between multiple requests?

As block2 is a critical option, how can a server know if a particular client supports this option?

Thank you,
Alexey

--------------020702090707060701080902-- From nobody Sat Apr 9 07:00:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8230712D6D6 for ; Sat, 9 Apr 2016 07:00:40 -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, WEIRD_PORT=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 rM_iyYFK2kQy for ; Sat, 9 Apr 2016 07:00:37 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECC712D5C1 for ; Sat, 9 Apr 2016 07:00:37 -0700 (PDT) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1818441C087; Sat, 9 Apr 2016 16:00:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id pe4IZ2uMi-vF; Sat, 9 Apr 2016 16:00:34 +0200 (CEST) X-Originating-IP: 190.111.246.156 Received: from nar.local (unknown [190.111.246.156]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id E202141C08B; Sat, 9 Apr 2016 16:00:32 +0200 (CEST) Message-ID: <57090AFC.8090808@tzi.org> Date: Sat, 09 Apr 2016 11:00:28 -0300 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Summary of second meeting at IETF95 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 14:00:40 -0000 ... and here is my summary of the Friday results. Again, please send in fixes and additions; the raw details are still at the same site: http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core Big thanks to the note takers! On Friday: * Handoff of the Baton: Barry Leiba gave his farewall as CoRE's responsible AD; great applause of the WG. * For the resource directory (RD) and related documents, we are aiming at WGLC before July 1st so we can discuss the outcome in Berlin and ship soon after. There are quite a few things to do, many of which are on the editorial level (see slides, but also Akbar's "advanced RD" document; we will not try to put mirror server/pubsub support in the RD document now, though). The issues will managed on the WG tracker. * There was in-room consensus to adopt draft-vanderstok-core-etch-00 as a WG document. This is needed to keep PATCH in the RD, but also for the management work (below). To be verified on the mailing list. * core-links-json also is in the same cluster (WGLC before July 1st). Hannes would like to see the RFC7390 parts separated out from the RFC6690 part that we are about for RD. The TODOs in the document need to be ticked off/trackerized. * There will be a 2nd WGLC for core-http-mapping after the comments are incorporated (-10). * core-interfaces may have been adopted too early and requires a major overhaul, separating out the more speculative material (some of which is T2TRG material). It should be made very clear that this describes one way of using CoAP (which has indeed been picked up in various ways by other SDOs), not the prescribed way. Matthias will help Michael to do the separation. * The work on management of constrained devices has converged ("COMI with COOL"). The yang-cbor draft is ready for an adoption call, but not enough people had read it yet to do an in-room adoption check. The other drafts will undergo merger/restructuring work based on this week's discussions and should then become ready for adoption. This work is explicitly covered by our charter (which also calls out LWM2M management as a related approach that we will continue to support as needed), and we will implicate NETMOD/NETCONF into every step we are taking. The author team invites the WG to its bi-weekly phone meetings (to be announced on core mailing list). * The work on Object Security for COAP (OSCOAP) is progressing nicely. A complete draft can be expected for Berlin. Grüße, Carsten Carsten Bormann wrote: > Here is my summary of what we did on Tuesday. > Fixes/additions welcome; details are in the draft minutes at > http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core > > On Tuesday: > > * Andrew indicated that he plans to step down as a WG chair and that > the ADs are looking for a replacement. > * As periodically, the AD is changing; this time from a graybeard > (Barry) to a blackbeard (Alexey). > * The chairs apologize for the infrequently updated milestones; fixing > them is up next. > * draft-ietf-core-block–19 is in IESG Evaluation, telechat date is > 2016–04–21. > * heads-up for new individual drafts: draft-kivinen-802-15-ie and > draft-bormann-6lo-coap-802-15-ie. > * CoAP over TCP received extensive discussion. Results (all to be > confirmed on the mailing list): > * #396: We revert the decision in Yokohama and go with alternative > L3. Procedurally, the pain of this reversal is balanced by the > reduced pain of not having to convince OCF to change their > specification. Technically, L3 is more open to evolving ideas about > message sizes. In any case, there is no intent to modify or > revoke section 4.6 of RFC 7252 at this time. > * We will need to examine the various proposals to add signaling to > the TCP connection (settings, ping/pong, release/abort). > Signaling messages (7.xx) is one possible mechanism for doing that. > * #387 (ALPN): We really need to make a decision here. > * Websockets: For merging the websockets draft into the TCP/TLS WG > document (with the websockets specific parts going to an > appendix), the authors of both drafts will discuss the merge. > * Multi-hop Security: Initial discussion of > draft-hartke-core-e2e-security-reqs. > * It is more well-defined what is being protected in a > request-response that spans a proxy than with a pub-sub broker. > * The current set of scenarios does not include the case that > security services are being performed by the intermediary. > Many such scenarios are conceivable; which ones have serious use > cases? > * Multicast (or, more generally, group communication) is not yet > being considered. > * Data Formats: WG to adopt SenML (to be confirmed on the mailing > list). After a bit of Brownian motion, the WG is now happy with the > way the data is formatted in -06 (base record with data, zero or > more records with more data). The addition of links in the data is > to be done by registering a senml label in core-links-json > ("reversing the arrow of dependency"). > > Friday meeting upcoming. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Sun Apr 10 05:22:36 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F144D12D51D for ; Sun, 10 Apr 2016 05:22:34 -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] 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 e38B4Gt26rLN for ; Sun, 10 Apr 2016 05:22:33 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1D512D0A5 for ; Sun, 10 Apr 2016 05:22:33 -0700 (PDT) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5C277A80C8; Sun, 10 Apr 2016 14:22:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id csJ_6LbqaWEH; Sun, 10 Apr 2016 14:22:29 +0200 (CEST) X-Originating-IP: 134.102.218.240 Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 8BC7BA809B; Sun, 10 Apr 2016 14:22:29 +0200 (CEST) Message-ID: <570A4583.2030100@tzi.org> Date: Sun, 10 Apr 2016 14:22:27 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:22:35 -0000 In Buenos Aires, we discussed the adoption of draft-veillette-core-yang-cbor-mapping-00 but not enough people had read the document to go for an in-room consensus call. This is a two-week call for adoption of draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. Specifically, if you (1) support or (2) have an objection to this decision, please speak up on the mailing list by 2016-04-24. Note that this work is explicitly covered by our charter, so discussions of which WG should work on this are off-topic. As always, adoption of a document as a WG document is not a vote on whether we already have reached last-call state; the intention is to work on the WG document after adoption for a while to get it ready for last call. If you want to combine your support/objection with technical comments, this is certainly welcome so we can accelerate that process. Grüße, Carsten From nobody Sun Apr 10 05:29:43 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2282F12D546 for ; Sun, 10 Apr 2016 05:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RUQHJMlJMn6 for ; Sun, 10 Apr 2016 05:29:40 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A803A12B007 for ; Sun, 10 Apr 2016 05:29:38 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id gcVc1s0064K0fSy01cVcyF; Sun, 10 Apr 2016 14:29:36 +0200 Received: from 2001:983:a264:1:f83a:b74e:8734:c08a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sun, 10 Apr 2016 14:29:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 10 Apr 2016 14:29:36 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <570A4583.2030100@tzi.org> References: <570A4583.2030100@tzi.org> Message-ID: <51e3f7b9421c753d0dd1ec941e7203fd@xs4all.nl> X-Sender: stokcons@xs4all.nl (y/1orCK2GBD39UAB7cr9W/46ESiHCbFT) User-Agent: XS4ALL Webmail Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:29:42 -0000 Dear all, I support the intention to work on the WG document after this adoption to get it ready for last call. More technical comments will follow, Peter Carsten Bormann schreef op 2016-04-10 14:22: > In Buenos Aires, we discussed the adoption of > draft-veillette-core-yang-cbor-mapping-00 but not enough people had > read > the document to go for an in-room consensus call. > > This is a two-week call for adoption of > draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. > Specifically, if you (1) support or (2) have an objection to this > decision, please speak up on the mailing list by 2016-04-24. > > Note that this work is explicitly covered by our charter, so > discussions > of which WG should work on this are off-topic. > > As always, adoption of a document as a WG document is not a vote on > whether we already have reached last-call state; the intention is to > work on the WG document after adoption for a while to get it ready for > last call. If you want to combine your support/objection with > technical > comments, this is certainly welcome so we can accelerate that process. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Apr 11 13:27:21 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5BD12F342 for ; Mon, 11 Apr 2016 13:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665, WEIRD_PORT=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 VUmXVWoAaS2o for ; Mon, 11 Apr 2016 13:27:18 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5D312F3EF for ; Mon, 11 Apr 2016 13:27:18 -0700 (PDT) X-ASG-Debug-ID: 1460406436-06daaa10a0ff160001-aa7cYp Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id r44d6FTWXEzAj9v2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Apr 2016 16:27:16 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Mon, 11 Apr 2016 16:27:15 -0400 From: "Rahman, Akbar" To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: Comments on proposed changes to draft-ietf-core-http-mapping X-ASG-Orig-Subj: Comments on proposed changes to draft-ietf-core-http-mapping Thread-Index: AdGULkDwKoTQS8fcTZW9boOCJcyTOw== Date: Mon, 11 Apr 2016 20:27:14 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.199] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253] X-Barracuda-Start-Time: 1460406436 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 6704 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=WEIRD_PORT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28647 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 WEIRD_PORT URI: Uses non-standard port number for HTTP Archived-At: Subject: [core] Comments on proposed changes to draft-ietf-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:27:20 -0000 SGkgQWxsLA0KDQoNCkF0IElFVEYtOTUgKEJ1ZW5vcyBBaXJlcykgd2UgZGlzY3Vzc2VkIG1vZGlm eWluZyBkcmFmdC1pZXRmLWNvcmUtaHR0cC1tYXBwaW5nIHRvOg0KDQogICAgICAgQ2xhcmlmeSB0 aGF0IHRoZSBzY29wZSBvZiBkcmFmdCBpcyBwcmltYXJpbHkgUmV2ZXJzZSBIQyBQcm94eSBidXQg dGhhdCBpdCBhbHNvIGNvdmVycyBnZW5lcmljIHByb3RvY29sIHRyYW5zbGF0aW9uIGFzcGVjdHMg dGhhdCBhcHBseSBhcyB3ZWxsIHRvIEZvcndhcmQgYW5kIEludGVyY2VwdGlvbiBIQyBQcm94eQ0K ICAgICAgICAgICAgICAg4pagIGUuZy4gUmVzcG9uc2Ugc3RhdHVzIG1hcHBpbmcgJiBjb250ZW50 IGZvcm1hdCBtYXBwaW5nIGFwcGx5IHRvIGFsbCB0eXBlcyBvZiBwcm94aWVzDQoNCg0KU3BlY2lm aWNhbGx5IHNlZSBwZy4gNzAtNzEgb2YgdGhlIEYyRiBwcmVzZW50YXRpb24gc2xpZGVzIHRoYXQg cHJlc2VudHMgdGhlIGRldGFpbHMgb2YgdGhlIHByb3Bvc2VkIGNoYW5nZXM6DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtY29yZS0wLnBkZg0K DQoNCldlIGhhZCBnb29kIHN1cHBvcnQgZHVyaW5nIHRoZSBGMkYgbWVldGluZyB0byBtYWtlIHRo ZXNlIGNoYW5nZXMuICBEb2VzIGFueW9uZSBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0aGlzIGFwcHJv YWNoPyAgSWYgeW91IGRvIHBsZWFzZSB3cml0ZSBiYWNrIHRvIHRoZSBsaXN0LiAgSWYgd2UgaGF2 ZSBub3QgcmVjZWl2ZWQgYW55IGNvbW1lbnRzIGJ5IEFwcmlsIDIyIHdlIHdpbGwgYXNzdW1lIHRo YXQgdGhpcyBkZWNpc2lvbiBpcyBzdXBwb3J0ZWQgYnkgdGhlIFdHIGFuZCB3aWxsIHByb2NlZWQg dG8gbWFrZSB0aGUgY2hhbmdlcyBzbyB0aGF0IHdlIGNhbiBzdGFydCB0aGUgbmV3IFdHTEMuDQoN Cg0KDQpUaGFua3MsDQoNCg0KQWtiYXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENh cnN0ZW4gQm9ybWFubg0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA5LCAyMDE2IDEwOjAwIEFNDQpU bzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtjb3JlXSBTdW1t YXJ5IG9mIHNlY29uZCBtZWV0aW5nIGF0IElFVEY5NQ0KDQouLi4gYW5kIGhlcmUgaXMgbXkgc3Vt bWFyeSBvZiB0aGUgRnJpZGF5IHJlc3VsdHMuDQoNCkFnYWluLCBwbGVhc2Ugc2VuZCBpbiBmaXhl cyBhbmQgYWRkaXRpb25zOyB0aGUgcmF3IGRldGFpbHMgYXJlIHN0aWxsIGF0IHRoZSBzYW1lIHNp dGU6IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0Zi05NS1j b3JlDQpCaWcgdGhhbmtzIHRvIHRoZSBub3RlIHRha2VycyENCg0KT24gRnJpZGF5Og0KDQoqIEhh bmRvZmYgb2YgdGhlIEJhdG9uOiBCYXJyeSBMZWliYSBnYXZlIGhpcyBmYXJld2FsbCBhcyBDb1JF J3MNCiByZXNwb25zaWJsZSBBRDsgZ3JlYXQgYXBwbGF1c2Ugb2YgdGhlIFdHLg0KKiBGb3IgdGhl IHJlc291cmNlIGRpcmVjdG9yeSAoUkQpIGFuZCByZWxhdGVkIGRvY3VtZW50cywgd2UgYXJlIGFp bWluZw0KIGF0IFdHTEMgYmVmb3JlIEp1bHkgMXN0IHNvIHdlIGNhbiBkaXNjdXNzIHRoZSBvdXRj b21lIGluIEJlcmxpbiBhbmQNCiBzaGlwIHNvb24gYWZ0ZXIuICBUaGVyZSBhcmUgcXVpdGUgYSBm ZXcgdGhpbmdzIHRvIGRvLCBtYW55IG9mIHdoaWNoDQogYXJlIG9uIHRoZSBlZGl0b3JpYWwgbGV2 ZWwgKHNlZSBzbGlkZXMsIGJ1dCBhbHNvIEFrYmFyJ3MgImFkdmFuY2VkDQogUkQiIGRvY3VtZW50 OyB3ZSB3aWxsIG5vdCB0cnkgdG8gcHV0IG1pcnJvciBzZXJ2ZXIvcHVic3ViIHN1cHBvcnQgaW4N CiB0aGUgUkQgZG9jdW1lbnQgbm93LCB0aG91Z2gpLiBUaGUgaXNzdWVzIHdpbGwgbWFuYWdlZCBv biB0aGUgV0cNCiB0cmFja2VyLg0KKiBUaGVyZSB3YXMgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRv cHQgZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWV0Y2gtMDANCiBhcyBhIFdHIGRvY3VtZW50LiAgVGhp cyBpcyBuZWVkZWQgdG8ga2VlcCBQQVRDSCBpbiB0aGUgUkQsIGJ1dCBhbHNvDQogZm9yIHRoZSBt YW5hZ2VtZW50IHdvcmsgKGJlbG93KS4gIFRvIGJlIHZlcmlmaWVkIG9uIHRoZSBtYWlsaW5nDQog bGlzdC4NCiogY29yZS1saW5rcy1qc29uIGFsc28gaXMgaW4gdGhlIHNhbWUgY2x1c3RlciAoV0dM QyBiZWZvcmUgSnVseSAxc3QpLg0KIEhhbm5lcyB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgUkZDNzM5 MCBwYXJ0cyBzZXBhcmF0ZWQgb3V0IGZyb20gdGhlDQogUkZDNjY5MCBwYXJ0IHRoYXQgd2UgYXJl IGFib3V0IGZvciBSRC4gIFRoZSBUT0RPcyBpbiB0aGUgZG9jdW1lbnQNCiBuZWVkIHRvIGJlIHRp Y2tlZCBvZmYvdHJhY2tlcml6ZWQuDQoqIFRoZXJlIHdpbGwgYmUgYSAybmQgV0dMQyBmb3IgY29y ZS1odHRwLW1hcHBpbmcgYWZ0ZXIgdGhlIGNvbW1lbnRzDQogYXJlIGluY29ycG9yYXRlZCAoLTEw KS4NCiogY29yZS1pbnRlcmZhY2VzIG1heSBoYXZlIGJlZW4gYWRvcHRlZCB0b28gZWFybHkgYW5k IHJlcXVpcmVzIGEgbWFqb3INCiBvdmVyaGF1bCwgc2VwYXJhdGluZyBvdXQgdGhlIG1vcmUgc3Bl Y3VsYXRpdmUgbWF0ZXJpYWwgKHNvbWUgb2YNCiB3aGljaCBpcyBUMlRSRyBtYXRlcmlhbCkuICBJ dCBzaG91bGQgYmUgbWFkZSB2ZXJ5IGNsZWFyIHRoYXQgdGhpcw0KIGRlc2NyaWJlcyBvbmUgd2F5 IG9mIHVzaW5nIENvQVAgKHdoaWNoIGhhcyBpbmRlZWQgYmVlbiBwaWNrZWQgdXAgaW4NCiB2YXJp b3VzIHdheXMgYnkgb3RoZXIgU0RPcyksIG5vdCB0aGUgcHJlc2NyaWJlZCB3YXkuICBNYXR0aGlh cyB3aWxsDQogaGVscCBNaWNoYWVsIHRvIGRvIHRoZSBzZXBhcmF0aW9uLg0KKiBUaGUgd29yayBv biBtYW5hZ2VtZW50IG9mIGNvbnN0cmFpbmVkIGRldmljZXMgaGFzIGNvbnZlcmdlZCAoIkNPTUkN CiB3aXRoIENPT0wiKS4gIFRoZSB5YW5nLWNib3IgZHJhZnQgaXMgcmVhZHkgZm9yIGFuIGFkb3B0 aW9uIGNhbGwsIGJ1dA0KIG5vdCBlbm91Z2ggcGVvcGxlIGhhZCByZWFkIGl0IHlldCB0byBkbyBh biBpbi1yb29tIGFkb3B0aW9uIGNoZWNrLg0KIFRoZSBvdGhlciBkcmFmdHMgd2lsbCB1bmRlcmdv IG1lcmdlci9yZXN0cnVjdHVyaW5nIHdvcmsgYmFzZWQgb24NCiB0aGlzIHdlZWsncyBkaXNjdXNz aW9ucyBhbmQgc2hvdWxkIHRoZW4gYmVjb21lIHJlYWR5IGZvciBhZG9wdGlvbi4NCiBUaGlzIHdv cmsgaXMgZXhwbGljaXRseSBjb3ZlcmVkIGJ5IG91ciBjaGFydGVyICh3aGljaCBhbHNvIGNhbGxz IG91dA0KIExXTTJNIG1hbmFnZW1lbnQgYXMgYSByZWxhdGVkIGFwcHJvYWNoIHRoYXQgd2Ugd2ls bCBjb250aW51ZSB0bw0KIHN1cHBvcnQgYXMgbmVlZGVkKSwgYW5kIHdlIHdpbGwgaW1wbGljYXRl IE5FVE1PRC9ORVRDT05GIGludG8gZXZlcnkNCiBzdGVwIHdlIGFyZSB0YWtpbmcuICBUaGUgYXV0 aG9yIHRlYW0gaW52aXRlcyB0aGUgV0cgdG8gaXRzIGJpLXdlZWtseQ0KIHBob25lIG1lZXRpbmdz ICh0byBiZSBhbm5vdW5jZWQgb24gY29yZSBtYWlsaW5nIGxpc3QpLg0KKiBUaGUgd29yayBvbiBP YmplY3QgU2VjdXJpdHkgZm9yIENPQVAgKE9TQ09BUCkgaXMgcHJvZ3Jlc3NpbmcgbmljZWx5Lg0K IEEgY29tcGxldGUgZHJhZnQgY2FuIGJlIGV4cGVjdGVkIGZvciBCZXJsaW4uDQoNCg0KR3LDvMOf ZSwgQ2Fyc3Rlbg0KDQoNCkNhcnN0ZW4gQm9ybWFubiB3cm90ZToNCj4gSGVyZSBpcyBteSBzdW1t YXJ5IG9mIHdoYXQgd2UgZGlkIG9uIFR1ZXNkYXkuDQo+IEZpeGVzL2FkZGl0aW9ucyB3ZWxjb21l OyBkZXRhaWxzIGFyZSBpbiB0aGUgZHJhZnQgbWludXRlcyBhdA0KPiBodHRwOi8vZXRoZXJwYWQu dG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25vdGVzLWlldGYtOTUtY29yZQ0KPg0KPiBPbiBUdWVzZGF5 Og0KPg0KPiAqIEFuZHJldyBpbmRpY2F0ZWQgdGhhdCBoZSBwbGFucyB0byBzdGVwIGRvd24gYXMg YSBXRyBjaGFpciBhbmQgdGhhdA0KPiAgIHRoZSBBRHMgYXJlIGxvb2tpbmcgZm9yIGEgcmVwbGFj ZW1lbnQuDQo+ICogQXMgcGVyaW9kaWNhbGx5LCB0aGUgQUQgaXMgY2hhbmdpbmc7IHRoaXMgdGlt ZSBmcm9tIGEgZ3JheWJlYXJkDQo+ICAgKEJhcnJ5KSB0byBhIGJsYWNrYmVhcmQgKEFsZXhleSku DQo+ICogVGhlIGNoYWlycyBhcG9sb2dpemUgZm9yIHRoZSBpbmZyZXF1ZW50bHkgdXBkYXRlZCBt aWxlc3RvbmVzOyBmaXhpbmcNCj4gICB0aGVtIGlzIHVwIG5leHQuDQo+ICogZHJhZnQtaWV0Zi1j b3JlLWJsb2Nr4oCTMTkgaXMgaW4gSUVTRyBFdmFsdWF0aW9uLCB0ZWxlY2hhdCBkYXRlIGlzDQo+ ICAgMjAxNuKAkzA04oCTMjEuDQo+ICogaGVhZHMtdXAgZm9yIG5ldyBpbmRpdmlkdWFsIGRyYWZ0 czogZHJhZnQta2l2aW5lbi04MDItMTUtaWUgYW5kDQo+ICAgZHJhZnQtYm9ybWFubi02bG8tY29h cC04MDItMTUtaWUuDQo+ICogQ29BUCBvdmVyIFRDUCByZWNlaXZlZCBleHRlbnNpdmUgZGlzY3Vz c2lvbi4gIFJlc3VsdHMgKGFsbCB0byBiZQ0KPiAgIGNvbmZpcm1lZCBvbiB0aGUgbWFpbGluZyBs aXN0KToNCj4gICAqICMzOTY6IFdlIHJldmVydCB0aGUgZGVjaXNpb24gaW4gWW9rb2hhbWEgYW5k IGdvIHdpdGggYWx0ZXJuYXRpdmUNCj4gICAgIEwzLiAgUHJvY2VkdXJhbGx5LCB0aGUgcGFpbiBv ZiB0aGlzIHJldmVyc2FsIGlzIGJhbGFuY2VkIGJ5IHRoZQ0KPiAgICAgcmVkdWNlZCBwYWluIG9m IG5vdCBoYXZpbmcgdG8gY29udmluY2UgT0NGIHRvIGNoYW5nZSB0aGVpcg0KPiAgICAgc3BlY2lm aWNhdGlvbi4gIFRlY2huaWNhbGx5LCBMMyBpcyBtb3JlIG9wZW4gdG8gZXZvbHZpbmcgaWRlYXMg YWJvdXQNCj4gICAgIG1lc3NhZ2Ugc2l6ZXMuICBJbiBhbnkgY2FzZSwgdGhlcmUgaXMgbm8gaW50 ZW50IHRvIG1vZGlmeSBvcg0KPiAgICAgcmV2b2tlIHNlY3Rpb24gNC42IG9mIFJGQyA3MjUyIGF0 IHRoaXMgdGltZS4NCj4gICAqIFdlIHdpbGwgbmVlZCB0byBleGFtaW5lIHRoZSB2YXJpb3VzIHBy b3Bvc2FscyB0byBhZGQgc2lnbmFsaW5nIHRvDQo+ICAgICB0aGUgVENQIGNvbm5lY3Rpb24gKHNl dHRpbmdzLCBwaW5nL3BvbmcsIHJlbGVhc2UvYWJvcnQpLg0KPiAgICAgU2lnbmFsaW5nIG1lc3Nh Z2VzICg3Lnh4KSBpcyBvbmUgcG9zc2libGUgbWVjaGFuaXNtIGZvciBkb2luZyB0aGF0Lg0KPiAg ICogIzM4NyAoQUxQTik6IFdlIHJlYWxseSBuZWVkIHRvIG1ha2UgYSBkZWNpc2lvbiBoZXJlLg0K PiAgICogV2Vic29ja2V0czogRm9yIG1lcmdpbmcgdGhlIHdlYnNvY2tldHMgZHJhZnQgaW50byB0 aGUgVENQL1RMUyBXRw0KPiAgICAgZG9jdW1lbnQgKHdpdGggdGhlIHdlYnNvY2tldHMgc3BlY2lm aWMgcGFydHMgZ29pbmcgdG8gYW4NCj4gICAgIGFwcGVuZGl4KSwgdGhlIGF1dGhvcnMgb2YgYm90 aCBkcmFmdHMgd2lsbCBkaXNjdXNzIHRoZSBtZXJnZS4NCj4gKiBNdWx0aS1ob3AgU2VjdXJpdHk6 IEluaXRpYWwgZGlzY3Vzc2lvbiBvZg0KPiAgIGRyYWZ0LWhhcnRrZS1jb3JlLWUyZS1zZWN1cml0 eS1yZXFzLg0KPiAgICogSXQgaXMgbW9yZSB3ZWxsLWRlZmluZWQgd2hhdCBpcyBiZWluZyBwcm90 ZWN0ZWQgaW4gYQ0KPiAgICAgcmVxdWVzdC1yZXNwb25zZSB0aGF0IHNwYW5zIGEgcHJveHkgdGhh biB3aXRoIGEgcHViLXN1YiBicm9rZXIuDQo+ICAgKiBUaGUgY3VycmVudCBzZXQgb2Ygc2NlbmFy aW9zIGRvZXMgbm90IGluY2x1ZGUgdGhlIGNhc2UgdGhhdA0KPiAgICAgc2VjdXJpdHkgc2Vydmlj ZXMgYXJlIGJlaW5nIHBlcmZvcm1lZCBieSB0aGUgaW50ZXJtZWRpYXJ5Lg0KPiAgICAgTWFueSBz dWNoIHNjZW5hcmlvcyBhcmUgY29uY2VpdmFibGU7IHdoaWNoIG9uZXMgaGF2ZSBzZXJpb3VzIHVz ZQ0KPiAgICAgY2FzZXM/DQo+ICAgKiBNdWx0aWNhc3QgKG9yLCBtb3JlIGdlbmVyYWxseSwgZ3Jv dXAgY29tbXVuaWNhdGlvbikgaXMgbm90IHlldA0KPiAgICAgYmVpbmcgY29uc2lkZXJlZC4NCj4g KiBEYXRhIEZvcm1hdHM6IFdHIHRvIGFkb3B0IFNlbk1MICh0byBiZSBjb25maXJtZWQgb24gdGhl IG1haWxpbmcNCj4gICBsaXN0KS4gIEFmdGVyIGEgYml0IG9mIEJyb3duaWFuIG1vdGlvbiwgdGhl IFdHIGlzIG5vdyBoYXBweSB3aXRoIHRoZQ0KPiAgIHdheSB0aGUgZGF0YSBpcyBmb3JtYXR0ZWQg aW4gLTA2IChiYXNlIHJlY29yZCB3aXRoIGRhdGEsIHplcm8gb3INCj4gICBtb3JlIHJlY29yZHMg d2l0aCBtb3JlIGRhdGEpLiAgVGhlIGFkZGl0aW9uIG9mIGxpbmtzIGluIHRoZSBkYXRhIGlzDQo+ ICAgdG8gYmUgZG9uZSBieSByZWdpc3RlcmluZyBhIHNlbm1sIGxhYmVsIGluIGNvcmUtbGlua3Mt anNvbg0KPiAgICgicmV2ZXJzaW5nIHRoZSBhcnJvdyBvZiBkZXBlbmRlbmN5IikuDQo+DQo+IEZy aWRheSBtZWV0aW5nIHVwY29taW5nLg0KPg0KPiBHcsO8w59lLCBDYXJzdGVuDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGlu ZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Mon Apr 11 22:37:29 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0654212E45C for ; Mon, 11 Apr 2016 22:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 0hdw_4CPsOQ9 for ; Mon, 11 Apr 2016 22:37:24 -0700 (PDT) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5D312E45B for ; Mon, 11 Apr 2016 22:37:23 -0700 (PDT) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id B85C019F3D8 for ; Tue, 12 Apr 2016 13:37:20 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.255.40.27]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 3046219F390; Tue, 12 Apr 2016 13:37:20 +0800 (HKT) Message-ID: <5C3EF16A6E1B441C8DC1BC2A8AF94F22@WeiGengyuPC> From: "weigengyu" To: References: <065.b1a2e6aa9c5600bacf4cf8ae258078b0@trac.tools.ietf.org> In-Reply-To: <065.b1a2e6aa9c5600bacf4cf8ae258078b0@trac.tools.ietf.org> Date: Tue, 12 Apr 2016 13:37:28 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: core@ietf.org Subject: Re: [core] #397 (coap-tcp-tls): CON usage with CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 05:37:28 -0000 Hi, The same situation is when a CON message goes through a C2C proxy. If that C2C proxy has one port with CoAP over UDP and one port with CoAP over TCP, the COM MSG should be converted to NON MSG by the current draft. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: core issue tracker Sent: Tuesday, April 05, 2016 9:46 AM To: draft-ietf-core-coap-tcp-tls@ietf.org ; Hannes.Tschofenig@gmx.net Cc: core@ietf.org Subject: [core] #397 (coap-tcp-tls): CON usage with CoAP over TCP #397: CON usage with CoAP over TCP In http://www.ietf.org/mail-archive/web/core/current/msg06988.html Timothy wrote: ---------------------------------------------------------- In section 4 Message Format says: The ’Message Length’ field is a 16-bit unsigned integer in network byte order. It provides the length of the subsequent CoAP message (including the CoAP header but excluding this message length field) in bytes (so its minimum value is 2). The Message ID and message type are meaningless and thus elided (what would have been the message type field is always filled with what would be the code for NON (01)). What would happen if an Application where to place a CON in the message type field. Based on my reading of this text I would expect the message type from the application to be ignored and the transport to put in a NON message. Is that correct? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-coap- Hannes.Tschofenig@gmx.net | tcp-tls@ietf.org Type: protocol defect | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Apr 13 16:30:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0333A12D6AE for ; Wed, 13 Apr 2016 16:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSNriewW1fm9 for ; Wed, 13 Apr 2016 16:30:07 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 57D2312D683 for ; Wed, 13 Apr 2016 16:30:07 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f105so54425529qge.2 for ; Wed, 13 Apr 2016 16:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lFURsecjaghYhBgErYxsg7hsadNNevwBe9v6dbTDYCQ=; b=m2XSPDe5fBTHFPsJ9l92b3dWbxoMY6kqNEPsExw1co7QzDGh2xWCsHkA9Js/IeArAv 4n77wz+dguTtqj3VYdf6KnnnASIKnenvUKVUrI7W935sEt8f02cL6GwfRn/6jQvtbE3m zfuxfoQVpLYrLZdTz6bURnl+mGF2QNlSqrohIHKX6xsgpF9Szh4SqPBnofM9El9X7NsH CGCtY+NKwKOkMeUuOVMQEgu43i0rZ5maebfG90fBXGB2CW6zReMVkOlN53BjI21n0NBh QrBnvXacsqfrrpXQ34SnhOJxfqlRePFWIPIeqCCe6Qy9Yl7p1+cXZ6OwuK+8lTH/OysG Q6IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lFURsecjaghYhBgErYxsg7hsadNNevwBe9v6dbTDYCQ=; b=jb6USlkXAYVUWrPAscFq0oKVaXl+njTWfR3Wj23IhtPkcihKZfCx4xBmdU6Hwc6aWh cPjZzVIssdcRj8MbNh6geErfQ5FZhWZwEGO3gIrOcvboIu2ibREIisgAsIvtBntru3wg x0B32p3+AfVyVe3qh1Pq/sEBvwNTC4/CnSuJ2Kgd/oZioUuJR69hCl6+JzWbDL6tzRd5 YPGXaNbcKTAw3Lt874zZtD8lBCY2LDoCYdm5aEY0gqeKK0+/wlJxQYZPfNxFIMU/T6EA W0ZkIwt0KZwd/rNNCGbF4fwPN/WSDiuFV9dE42vF7x3EVFidy4YMLrulKg2TgN3ptKqf RPug== X-Gm-Message-State: AOPr4FVHHUQNW9WGr8vFyxHIr3Lsrz2g8fDQ1AvkR6CXjntpsOKHNh66MSPNHtXXO1ZlHEuNisaVwoY/bfQsAw== X-Received: by 10.140.90.106 with SMTP id w97mr14956397qgd.14.1460590206350; Wed, 13 Apr 2016 16:30:06 -0700 (PDT) MIME-Version: 1.0 References: <57054B35.50700@tzi.org> In-Reply-To: <57054B35.50700@tzi.org> From: Simon Lemay Date: Wed, 13 Apr 2016 23:29:56 +0000 Message-ID: To: Carsten Bormann , "core@ietf.org WG" Content-Type: multipart/alternative; boundary=001a11c11a24697c2305306628c3 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_CoAP_over_TCP/?= =?utf-8?q?TLS_=23396=3A_Revert_L1_selection=2C_select_L3?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 23:30:09 -0000 --001a11c11a24697c2305306628c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Sorry for missing the meeting, but I had a few questions concerning the decision, not that I am not necessarily oppose to the change, but I does come as a surprise. I know one of the main concern of L3 in the pass was the possibility of head-of-line blocking, should we still consider bert draft that was proposed. The other concern was on how smaller device fit in this, if you send large payload that are out of scope for a constraint device, how should this be handle (if should be handle that the procol level) Cheers Simon On Wed, Apr 6, 2016 at 10:45 AM Carsten Bormann wrote: > As discussed in a previous message, the in-room consensus in Buenos > Aires was to revert the decision we made in Yokohama to go for > alternative L1, and to instead select alternative L3. > > This is a one-week call for confirmation of that decision. > Specifically, if you have an objection to this decision, please speak up > on the mailing list by 2016-04-13. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11c11a24697c2305306628c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

Sorry for missing t= he meeting, but I had a few questions concerning the decision, not that=C2= =A0I am not necessarily oppose to the change, but I does come as a surprise= .=C2=A0

I know one of the main concern of L3 in the pass= was the possibility of head-of-line blocking, should we still consider ber= t draft that was proposed.

The other concern was o= n how smaller device fit in this, if you send large payload that are out of= scope for a constraint device, how should this be handle (if should be han= dle that the procol level)

Cheers

Simon

O= n Wed, Apr 6, 2016 at 10:45 AM Carsten Bormann <cabo@tzi.org> wrote:
As discussed in a previous message, the in-room consensus in Buenos
Aires was to revert the decision we made in Yokohama to go for
alternative L1, and to instead select alternative L3.

This is a one-week call for confirmation of that decision.
Specifically, if you have an objection to this decision, please speak up on the mailing list by 2016-04-13.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--001a11c11a24697c2305306628c3-- From nobody Wed Apr 13 18:01:13 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5E12D588 for ; Wed, 13 Apr 2016 18:01:11 -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] 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 COMAvVUVScrs for ; Wed, 13 Apr 2016 18:01:10 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1DA12D50A for ; Wed, 13 Apr 2016 18:01:09 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 05B90C5A5C; Thu, 14 Apr 2016 03:01:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id e7tlVCgm54_v; Thu, 14 Apr 2016 03:01:06 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-2.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 17A32C5A4E; Thu, 14 Apr 2016 03:01:05 +0200 (CEST) Message-ID: <570EEBD0.6040408@tzi.org> Date: Thu, 14 Apr 2016 03:01:04 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Simon Lemay References: <57054B35.50700@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_CoAP_over_TCP/?= =?utf-8?q?TLS_=23396=3A_Revert_L1_selection=2C_select_L3?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 01:01:12 -0000 Hi Simon, good to hear from you -- this is exactly why we validate in-room decisions on the mailing list. > I know one of the main concern of L3 in the pass was the possibility of > head-of-line blocking, should we still consider bert draft that was > proposed. That is not a concern with L3, but a concern with large messages. Yes, these do exhibit head-of-line blocking. BERT is a good way to control the extent of this blocking, so I think this is still a useful extension to pursue. > The other concern was on how smaller device fit in this, if you send > large payload that are out of scope for a constraint device, how should > this be handle (if should be handle that the procol level) As we said, there is no intention to revoke the SHOULDs in section 4.6 of RFC 7252. However, there is also no intention to enforce these SHOULDs (policy) by providing an artificial limitation to the message size (mechanism) at the encapsulation level. L3 does not prevent you from shooting yourself in the foot by ignoring section 4.6 (note that L2 didn't really do that, either, 64 KiB is still larger than 1152). But L3 also doesn't stop you from transcending 4.6 significantly if you have a good reason to do so. Grüße, Carsten From nobody Sun Apr 17 06:00:46 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5735712D587 for ; Sun, 17 Apr 2016 06:00:44 -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] 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 tLhHgzuMRNnb for ; Sun, 17 Apr 2016 06:00:41 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEA112D5B3 for ; Sun, 17 Apr 2016 06:00:41 -0700 (PDT) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 62A18C5A56; Sun, 17 Apr 2016 15:00:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LRedk4dLuiBv; Sun, 17 Apr 2016 15:00:37 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-2.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 6B83CC5A3C; Sun, 17 Apr 2016 15:00:37 +0200 (CEST) Message-ID: <571388EF.70705@tzi.org> Date: Sun, 17 Apr 2016 15:00:31 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" References: <57054A86.7050702@tzi.org> In-Reply-To: <57054A86.7050702@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_WG_adoption_of?= =?utf-8?q?_draft-jennings-core-senml-06?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 13:00:44 -0000 There were no objections to the in-room consensus to adopt this document. Authors: Please resubmit the draft as draft-ietf-core-senml-00. Grüße, Carsten Carsten Bormann wrote: > As discussed in the previous message, the in-room consensus in Buenos > Aires was to adopt draft-jennings-core-senml-06 as a CoRE WG draft. > > This is a one-week call for confirmation of that decision. > Specifically, if you have an objection to this decision, please speak up > on the mailing list by 2016-04-13. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > From nobody Sun Apr 17 07:50:07 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39212D986 for ; Sun, 17 Apr 2016 07:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNnRF9Gasdqx for ; Sun, 17 Apr 2016 07:50:04 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 C355612D7F4 for ; Sun, 17 Apr 2016 07:50:03 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f52so104351822qga.3 for ; Sun, 17 Apr 2016 07:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YlxoWVyF+SyGhRiDEFTAwDJkxqsYKlR6SsH7fIieayg=; b=s0/SMYWoxfbreb1tNx0H860eZrOHgZRQw58svHl9AvrmRh1Al1ps/IojnCVJfOnEZE q0A1owTwan0bzGP28SOSccF55yJM67rbwh6pJqhFs8mSsKBMIaVnhTb4TNuXPBztBfHD ObieM+HFR/8O92WW7BfYJSjzCspZqOgUn53iNGm/A9ltErpXWG6XBNUGMtNLgLUY7iG9 JHkIbXjHOL/4oTO+zH5x/NBC7KFVfc26jPQ3mmTwxytSPvNybN0A6XVPCI9Nd+yKLKz4 kjM2m3cjyscR7oN/YDvqr4MQi6mdy/AjBKf6Q3EOp4N9tMqA7hTdt1eC6ZB024N7xu8S y8cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YlxoWVyF+SyGhRiDEFTAwDJkxqsYKlR6SsH7fIieayg=; b=lDqTOwVofa+SUo5y8Z6zHkgIn+y8T6vUKdC1SPaDOnzZtLdtrX3reQ0H+LPr0/jlfJ 7amQycnAl7B6agt/LgnV4fI/equ+50Ax2r8gcgVIyr/ppnfrkUPLEaxOarLRdb0I6rs5 Q8lfy/11b17DFEXhHeaBsQ81eZAQ0Jv7ywaBplzK8LomN+oG90+6mDuwdN0YeQp1A4we TKjO2yjDd4/J7wadHg2gSHeYBYweawtqtOGK2Fuzn5yuTNOdMHuXbqYH/Z0xZcN+lPOY KIYj+igea+o8L3vDalB43Q6NHb1P9l6+rs9O4opYr71snd8bdCQSoCZEjdlJuykUJEy2 KGHA== X-Gm-Message-State: AOPr4FVGD3yDPQbnZoycROMYfrVvXx2Pp6lyRoVHy84FrAePtJnWCY5wimz/Lyn0hxAF6OGkIL936jmzp8ZunQ== X-Received: by 10.140.246.86 with SMTP id r83mr20827607qhc.65.1460904602938; Sun, 17 Apr 2016 07:50:02 -0700 (PDT) MIME-Version: 1.0 References: <57054B35.50700@tzi.org> <570EEBD0.6040408@tzi.org> In-Reply-To: <570EEBD0.6040408@tzi.org> From: Simon Lemay Date: Sun, 17 Apr 2016 14:49:53 +0000 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1139bd76e8c2100530af5bf6 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_CoAP_over_TCP/?= =?utf-8?q?TLS_=23396=3A_Revert_L1_selection=2C_select_L3?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 14:50:05 -0000 --001a1139bd76e8c2100530af5bf6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Thanks for the answer, When I said L3 I guess I implied larger payload, but yes this makes sense. And I do believe that we should keep working on BERT. I also think we should have something in place so constraint device can refuse a message if too large But yes this make sense, thanks for the explanation. Simon On Wed, Apr 13, 2016 at 18:01 Carsten Bormann wrote: > Hi Simon, > > good to hear from you -- this is exactly why we validate in-room > decisions on the mailing list. > > > I know one of the main concern of L3 in the pass was the possibility of > > head-of-line blocking, should we still consider bert draft that was > > proposed. > > That is not a concern with L3, but a concern with large messages. > Yes, these do exhibit head-of-line blocking. > BERT is a good way to control the extent of this blocking, so I think > this is still a useful extension to pursue. > > > The other concern was on how smaller device fit in this, if you send > > large payload that are out of scope for a constraint device, how should > > this be handle (if should be handle that the procol level) > > As we said, there is no intention to revoke the SHOULDs in section 4.6 > of RFC 7252. However, there is also no intention to enforce these > SHOULDs (policy) by providing an artificial limitation to the message > size (mechanism) at the encapsulation level. > > L3 does not prevent you from shooting yourself in the foot by ignoring > section 4.6 (note that L2 didn't really do that, either, 64 KiB is still > larger than 1152). But L3 also doesn't stop you from transcending 4.6 > significantly if you have a good reason to do so. > > Gr=C3=BC=C3=9Fe, Carsten > --001a1139bd76e8c2100530af5bf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

Thanks for the answ= er,

When I said L3 I guess I implied larger payload, but yes this m= akes sense. And I do believe that we should keep working on BERT.

I= also think we should have something in place so constraint device can refu= se a message if too large

But yes this make sense, thanks for the ex= planation.

Simon


On Wed, Apr 13, 2016 at 18:01 Carsten Bormann <cabo@tzi.org> wrote:
Hi Simon,

good to hear from you -- this is exactly why we validate in-room
decisions on the mailing list.

> I know one of the main concern of L3 in the pass was the possibility o= f
> head-of-line blocking, should we still consider bert draft that was > proposed.

That is not a concern with L3, but a concern with large messages.
Yes, these do exhibit head-of-line blocking.
BERT is a good way to control the extent of this blocking, so I think
this is still a useful extension to pursue.

> The other concern was on how smaller device fit in this, if you send > large payload that are out of scope for a constraint device, how shoul= d
> this be handle (if should be handle that the procol level)

As we said, there is no intention to revoke the SHOULDs in section 4.6
of RFC 7252.=C2=A0 However, there is also no intention to enforce these
SHOULDs (policy) by providing an artificial limitation to the message
size (mechanism) at the encapsulation level.

L3 does not prevent you from shooting yourself in the foot by ignoring
section 4.6 (note that L2 didn't really do that, either, 64 KiB is stil= l
larger than 1152).=C2=A0 But L3 also doesn't stop you from transcending= 4.6
significantly if you have a good reason to do so.

Gr=C3=BC=C3=9Fe, Carsten
--001a1139bd76e8c2100530af5bf6-- From nobody Sun Apr 17 21:48:09 2016 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 74ECC12DE55; Sun, 17 Apr 2016 21:48:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160418044805.28780.94432.idtracker@ietfa.amsl.com> Date: Sun, 17 Apr 2016 21:48:05 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 04:48:05 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider whether you need to say more about UDP usage for this extension than what the base CORE specification says - RFC 7252 has only one mention of RFC 5405, and that only points to guidance about reducing ACK_TIMEOUT below one second. I understand that the CoAP story includes "most of these nodes aren't capable of generating a lot of packets in a short timeframe", but does this extension make it easier to send multiple UDP packets back-to-back? I'm reading this text, In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. and then this text * The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set. (SZX does not govern the payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX down to the size given in the response. (The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.) and realizing that I'm confused about why all the blocks for a body might NOT use the same block size. Maybe this doesn't matter (because an implementation would need to be prepared for the case when all the blocks don't use the same block size)? The examples were helpful to me. Thank you for doing that work. From nobody Mon Apr 18 03:23:26 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A112DE08; Mon, 18 Apr 2016 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 pIHfCm9WmYAw; Mon, 18 Apr 2016 03:23:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549D412DDF9; Mon, 18 Apr 2016 03:23:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHT94160; Mon, 18 Apr 2016 09:56:42 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 10:56:34 +0100 Received: from BLREML509-MBB.china.huawei.com ([169.254.1.138]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Mon, 18 Apr 2016 15:26:24 +0530 From: Vasu Kantubukta To: "core@ietf.org" , "ace@ietf.org" Thread-Topic: New Version Notification for draft-vasu-ace-core-access-privilege-provisioning-00.txt Thread-Index: AQHRlzE4W5soGoneV0Ws+BItK+DdmJ+PgGNg Date: Mon, 18 Apr 2016 09:56:23 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.211.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Ashutosh prakash , Javed siddiqui , "Zuojing \(2012 Laboratories\)" Subject: [core] FW: New Version Notification for draft-vasu-ace-core-access-privilege-provisioning-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 10:23:25 -0000 RGVhciBDT1JFIGFuZCBBQ0UsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgb24gImFjY2Vz cyBwcml2aWxlZ2UgcHJvdmlzaW9uaW5nIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIiB0aGF0IHBy b3ZpZGVzIGEgbWV0aG9kIHRvIGNvbmZpZ3VyZSB0aGUgcG9saWNpZXMgZm9yIGFkbWlzc2lvbiBh cyB3ZWxsIGFzIHJlc291cmNlIGNvbnRyb2wgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnQgKGlu Y2x1ZGluZyBib3RoIGNvbnN0cmFpbmVkIGFuZCBub24tY29uc3RyYWluZWQgZGV2aWNlcykgd2hp Y2ggaW5jbHVkZXMgY29tcGxldGUgc3lzdGVtIGFyY2hpdGVjdHVyZSwgbWV0aG9kcyBmb3IgZGVm aW5pbmcgcG9saWNpZXMsIGFuZCB3aXRoIGNvbW1pc3Npb25pbmcgcHJvY2VkdXJlcy4gSGVyZSwg dGhlIHNlcnZpY2UgcHJvdmlzaW9uaW5nIGluY2x1ZGVzIGF1dGhlbnRpY2F0aW9uLCBhdXRob3Jp emF0aW9uLCBhZG1pc3Npb24gYW5kIHJlc291cmNlIGNvbnRyb2wuDQoNClRoZSBkcmFmdCBkZXRh aWxzIGFib3V0IHRoZSBmb2xsb3dpbmc6DQoNCjEpIERpc2NvdmVyIHByb3Zpc2lvbmluZyBzZXJ2 ZXIsIGFuZCB2ZXJpZnkgcmVnaXN0ZXJlZCBzZXJ2aWNlIHdpdGggQ09SRS1SRCB1c2luZyBjb21t aXNzaW9uaW5nIHByb2NlZHVyZS4NCjIpIERlZmluaW5nIGFkbWlzc2lvbiBjb250cm9sIHBvbGlj aWVzIGZvciByZWdpc3RlcmVkIHJlc291cmNlcy4NCjMpIEhvdyByZXNvdXJjZSBjb250cm9sIHBv bGljaWVzIGNhbiBiZSBjb25maWd1cmVkIHRvIGFsbG93IG9ubHkgcHJpdmlsZWdlZCB1c2VycyB0 byBhY2Nlc3MgdGhlIHJlc291cmNlPw0KDQpXZSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgdGhlIENv UkUsIGFuZCBBQ0UgYXNwZWN0cyBvZiB0aGlzIGRyYWZ0IGluIHRoZSBDT1JFIGFuZCBBQ0UgV0cg bWVldGluZy4NCg0KVGhhbmtzIGFuZCBCZXN0IFJlZ2FyZHMNCksgVmFzdQ0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogMjAxNuW5tDTmnIgxNeaXpSAyMTo0 MA0KVG86IFJhaHVsIEFydmluZCBKYWRoYXYgKFJhaHVsIEFydmluZCBKYWRoYXYsIDIwMTIgTGFi cyk7IFZhc3UgS2FudHVidWt0YTsgVmFzdSBLYW50dWJ1a3RhOyBZYW5nbmVuZzsgUmFodWwgQXJ2 aW5kIEphZGhhdiAoUmFodWwgQXJ2aW5kIEphZGhhdiwgMjAxMiBMYWJzKQ0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC12YXN1LWFjZS1jb3JlLWFjY2Vzcy1wcml2 aWxlZ2UtcHJvdmlzaW9uaW5nLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC12YXN1LWFjZS1jb3JlLWFjY2Vzcy1wcml2aWxlZ2UtcHJvdmlzaW9uaW5nLTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLYW50dWJ1a3RhIFZhc3UgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtdmFzdS1hY2UtY29yZS1h Y2Nlc3MtcHJpdmlsZWdlLXByb3Zpc2lvbmluZw0KUmV2aXNpb246CTAwDQpUaXRsZToJCUFjY2Vz cyBQcml2aWxlZ2UgUHJvdmlzaW9uaW5nIGZvciBDb25zdHJhaW5lZCBEZXZpY2VzDQpEb2N1bWVu dCBkYXRlOgkyMDE2LTA0LTE1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6 CQkzMA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC12YXN1LWFjZS1jb3JlLWFjY2Vzcy1wcml2aWxlZ2UtcHJvdmlzaW9uaW5nLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXZhc3UtYWNlLWNvcmUtYWNjZXNzLXByaXZpbGVnZS1wcm92aXNpb25pbmcvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZhc3UtYWNlLWNvcmUtYWNj ZXNzLXByaXZpbGVnZS1wcm92aXNpb25pbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIEFzIG1vcmUg Y29uc3RyYWluZWQgZGV2aWNlcyBhcmUgaW50ZWdyYXRpbmcgd2l0aCBjdXJyZW50IEludGVybmV0 LA0KICAgdGhlIHViaXF1aXRvdXMgY29tcHV0aW5nIGluIHNjZW5hcmlvcyBsaWtlIHNtYXJ0IGhv bWUgaXMgdmVyeQ0KICAgaW1wb3J0YW50LiBJbiBzbWFydCBob21lLCB0aGUgY29uc3RyYWluZWQg ZGV2aWNlcyAoZXguIHRoZXJtb3N0YXQpDQogICBuZWVkIHRvIGJlIHByb3Zpc2lvbmVkIGluIHN1 Y2ggYSB3YXkgdGhhdCBpdCBjYW4gaW50ZXItb3BlcmF0ZSB3aXRoDQogICBhbnkga2luZCBvZiBk ZXZpY2VzIGxpa2Ugb3RoZXIgY29uc3RyYWluZWQgZGV2aWNlcyAoZXguIEFpcg0KICAgY29uZGl0 aW9uZXIpIG9yIGNsaWVudCBkZXZpY2VzIChleC4gc21hcnQgcGhvbmUpLiBUaGlzIGRvY3VtZW50 DQogICBwcm92aWRlcyBhIG1ldGhvZCB0byBzdXBwb3J0IGFjY2VzcyBwcml2aWxlZ2UgcHJvdmlz aW9uaW5nIGJhc2VkIG9uDQogICBwcmUtY29uZmlndXJlZCBhZG1pc3Npb24gYW5kIHJlc291cmNl IGNvbnRyb2wgcG9saWNpZXMsIHdoZXJlIHRoaXMNCiAgIG1ldGhvZCBleHBsYWlucyBkZXZpY2Un cyBzZXJ2aWNlIGFjY2VzcyBpbiB0d28gZGlmZmVyZW50IHVzZSBjYXNlczoNCiAgIGZpcnN0IHBy b3Zpc2lvbmluZyB0aGUgc2VydmljZSB3aGVuIGEgY29uc3RyYWluZWQgZGV2aWNlIGFjY2Vzc2lu Zw0KICAgdGhlIHNlcnZpY2UgcHJvdmlkZWQgYnkgb3RoZXIgY29uc3RyYWluZWQgZGV2aWNlLCBz ZWNvbmQsIGFjY2Vzc2luZw0KICAgdGhlIHNlcnZpY2UgcHJvdmlkZWQgYnkgY29uc3RyYWluZWQg ZGV2aWNlIGZyb20gdGhlIGNsaWVudCBkZXZpY2UNCiAgIChub24gY29uc3RyYWluZWQgZGV2aWNl KS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Apr 18 20:24:42 2016 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 8B3C312D094; Mon, 18 Apr 2016 20:24:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419032438.11079.43000.idtracker@ietfa.amsl.com> Date: Mon, 18 Apr 2016 20:24:38 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Ben Campbell's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 03:24:38 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-block-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be easy to clean up, and it's entirely possible I am misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading the following: 1. If the client requests a specific block size, the server MUST use that size or a smaller one. 2. Any subsequent requests from the client MUST indicate the same size that the server used 3. But paragraph 3 then says all further requests SHOULD indicate the same size. But if they already MUST indicate the same size as in the initial response, then this SHOULD seems non-constraining at best, and at worst in conflict with 1. (ignoring the last-block size issue for the moment.) 4. Then paragraph 3 goes on to say the server SHOULD use the block size indicated in the request or smaller. This seems to conflict with the MUST in 1. 5. Then it again asserts that the client MUST indicate the same size in subsequent requests, conflicting with the SHOULD in 3., but agreeing with the MUST in 1. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - General: The draft dives into detail without giving much context until the examples. The reader is left to infer the forest from the trees. It would be very helpful (to me, at least) to add a high-level overview of operation early in the document, including definitions for "descriptive" vs " control" usages. (I know it's late in the process to ask for a whole new section, so I won't push the point.) - The distinction between the option names Block1 and Block2 seems almost actively non-mnemonic. Is that intentional? (I won't push this point, either.) - 3.4: Does the eTag apply to the "payload" or the whole "body"? - 2.5, 2nd paragraph, last sentence: Should I read this to mean that the reduction in block size is retroactive? That could use some elaboration. (I thought I read comments in the examples suggesting such a reduction would _not_ be retroactive). - 7: Does "object security" apply to the "payload", or the "body"? Can you describe or add a reference for the "usual considerations"? Editorial: - Abstract: That’s a really long abstract, and serves more as an introduction than an abstract. Please consider combining the first and last paragraph and leaving the rest to the introduction. - 2.4, paragraph 5: a definition for "reassembler" would be helpful. - Figures 5 and 6: There's no discussion of either figure. Is that intentional? From nobody Tue Apr 19 04:48:17 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFE12DBA0 for ; Tue, 19 Apr 2016 04:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 UE-_s2UVPjyp for ; Tue, 19 Apr 2016 04:48:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E869E12D99F for ; Tue, 19 Apr 2016 04:48:10 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MNqcR-1apz1o2MSB-007RNv for ; Tue, 19 Apr 2016 13:48:07 +0200 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <57161AFB.5040804@gmx.net> Date: Tue, 19 Apr 2016 13:48:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aI7W8E4OkPQJkr9rv0PdgjutWD3sRk1fa" X-Provags-ID: V03:K0:4P9i+m+3CxaVhRsh9kQj9rLkV0bWbf/E5c0m/dXF/2s8WeN+EcM BS1wtdRp98euoOcqcdx9yCmqnC0+GNHdUACHpe8SLQ7G9a0HE1z9LgOHfABwNoLag/D8Kk9 JgllduaCqJxO4ZrI+Vy8kBH6DEOD6Ks1A++5yYdv1VKEexJVFM471EGofaETGAswXUe6TJ8 OtoDVyT2qhoQS2QYWFlcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:qBZ83B7vOlg=:t77s1MFa6pZT+SkUisbfNt NAOqifh7H8JJutPlBHcF1V+pxjalL/c5ZEm+Hh4XvLU+7fV/ngY0YpSdtLZ2Sf46Ao9jcQPrE T8FV9voASrjJIPOaT3xC5fpAqhUhajoqBeRtvdeTMl9u9VnEC4Kj0JgmP0hvmxykkM6rEy+iR q3uxfMtONCBnGJyZXE9z5OmszJXv87rW9W4i6XH+0H3HvDo3A/qGnRbhaEwPdYqv7paNF0/Y3 iizwrS6L0UeiJyAfCm5qV+0yjGrF2NysEYiQFlgElZQuhGCxemMhkFhba566qn2n1Q10nj8dj MFrU7zNCgW0vK7AvMiKKRC25RhVnKNiYY1bDyNknsC2YMHtIbcsp0lAfFDwj0AXMknO1Wretz ONnFmIb/jemdnL9Maa2NmTLkXGL61RfmfHujtwpXaNIO0t7oWHaMpdlVRc+iaFBdSwMmuTTp1 XlEoNqgx2LbaTmpSrvot8PgqZoW+lvYLYcJGy1dKgF/RPYTRIecgkQa9Te3KfTF018q3v1LKr YLR33JyZ47hfdaanJnikeR7BGrgRd6CwGSIrc8MR2ACRhCJlXSRjTI+Ec27QMvLBYWvhM05/x 9pEb9cMy9sSYInd3Sz071p/4uDdbaE1OCX+h+3E9q7ZXsQkQLgTzO0wTfe709KXeXfFlOJ4rc T7ieXJYVbeR/PYoOd9atVAMPcFBaHJq91DrDfwuyRbrG2kEB/tb5QpiDODWb1asJz5OjVGsZL uZOcMs9TpN3j+lXgwnrjkGU0EwqNzQWpibJivrCvv25B6A72+tKe6eDybOA= Archived-At: Subject: [core] Issue Tracking of Working Group Items X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:48:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aI7W8E4OkPQJkr9rv0PdgjutWD3sRk1fa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, at the last IETF meeting we talked about the open issues with the working group items and identified various issues that need to be tackled with high priority. The document editors wanted to add the open issues to the WG tracker. I have just looked at the tracker at https://trac.tools.ietf.org/wg/core/trac/report/1 and, unfortunately, nobody has added any issues. If we indeed want to complete many of the WG items by the Berlin IETF meeting then we should at least add the open issues to the tracker before we can resolve them one-by-one. It is not even clear to me who is in charge (editor) for each of the WG documents. If there isn't even enough energy by the authors to identify the open issues and to add them to the tracker then the group is in trouble and IMHO should definitely not adopt new WG documents. Ciao Hannes --aI7W8E4OkPQJkr9rv0PdgjutWD3sRk1fa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEbBAEBCgAGBQJXFhr8AAoJEGhJURNOOiAtjzkH+KnX0P8Os9c+0l6KKrdeyhkq +xlnYuxub/7ss+nsEgKrt9hXitRuuiBvNNeniVDl26G7IPxPok+jX1/3OyVj2rKd XZ1+pJq+6plW3jcgy+uL6c9PdMrlIrc2xlHog0Y+QzCqwENDWABMV8uw73Qqifi3 RcVLSrGFc0nA5ZHSVTJy7D3tlFAFiGvR6PzJ0iGKKAKj+v78FHOmFucqY1nEipTQ 7MOYFzrvKgFWT1/+exbWTZfN/GbvD3B3Bsh22ibgIXwcVQq0CUY8JBVOr4LjgUiQ lcwP6hJLk7x5dKttl3K+Ocm2smruA2N5zq0Uik0KcGy+c/ozugZKExWczvJoFQ== =4xTI -----END PGP SIGNATURE----- --aI7W8E4OkPQJkr9rv0PdgjutWD3sRk1fa-- From nobody Tue Apr 19 05:10:36 2016 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 4D0DA12E36D; Tue, 19 Apr 2016 05:10:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419121034.31581.55883.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 05:10:34 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Stephen Farrell's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:10:34 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The intro and early section 2 has quite a bit of argument as to why this design is good or better than some other. For this reader, that's not really needed (I assume the WG had those discussions). I think this is an example of a recurring problem with the text here - with too many words, clarity suffers. For example the Implementation note on p7 is, just by itself, the best and would be a sufficient explanation of, the encoding, the description of which is otherwise pretty opaque. There's also a good bit of repetition that makes this a harder read in general. That's all just IMO of course, and there may be history in the WG that provides good cause for so many words to be needed. All that said, I assume that it's too late to reduce the size of this document, so no action is required unless the authors/WG/chairs would themselves like to try remove words. From nobody Tue Apr 19 05:34:55 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A8312DA25 for ; Tue, 19 Apr 2016 05:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 IkN2xhJyvn80 for ; Tue, 19 Apr 2016 05:34:51 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 7BD9612D17C for ; Tue, 19 Apr 2016 05:34:51 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 1E7C6C4B26034 for ; Tue, 19 Apr 2016 12:34:47 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u3JCYnWN003717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Apr 2016 12:34:49 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u3JCYlZ8024765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Apr 2016 12:34:49 GMT Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 19 Apr 2016 08:34:48 -0400 Received: from SG70YWXCHMBA08.zap.alcatel-lucent.com ([169.254.8.20]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.03.0195.001; Tue, 19 Apr 2016 20:34:16 +0800 From: "Subramani, Padmakumar (Nokia - IN)" To: "core@ietf.org" Thread-Topic: OMA LWM2M & Dependencies on IETF CoRE - Requesting Thread-Index: AQHRmjfIGgogCuquqUueebPfCi+Lpg== Date: Tue, 19 Apr 2016 12:34:15 +0000 Message-ID: <30BE9EF0-4A9C-48E6-B158-493E19C30D1E@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151206 x-originating-ip: [135.253.19.16] Content-Type: multipart/alternative; boundary="_000_30BE9EF04A9C48E6B158493E19C30D1Ealcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: [core] OMA LWM2M & Dependencies on IETF CoRE - Requesting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:34:53 -0000 --_000_30BE9EF04A9C48E6B158493E19C30D1Ealcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDb1JFIFdvcmtpbmcgR3JvdXAgQ2hhaXJzLA0KSGkgYWxsLA0KDQpJIGFtIGNvLWNoYWly IG9mIHRoZSBPTUEgRGV2aWNlIE1hbmFnZW1lbnQgd29ya2luZyBncm91cCwgd2hvIGRldmVsb3Bz IHRoZSBMV00yTSBzcGVjaWZpY2F0aW9uLiBXZSBhcmUgY3VycmVudGx5IGluIHRoZSBwcm9jZXNz IG9mIGRlZmluaW5nIHZlcnNpb24gMS4xIG9mIHRoZSBMV00yTSBwcm90b2NvbCBhbmQgd291bGQg bGlrZSB0byByZS11c2UgYXMgbWFueSBJRVRGIHNwZWNpZmljYXRpb25zIGFzIHBvc3NpYmxlLg0K DQpGb3IgdGhpcyBwdXJwb3NlIHdlIGFyZSBzZWVraW5nIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9u IGFib3V0IHRoZSBzdGF0dXMgb2YgdGhlIGZvbGxvd2luZyBzcGVjaWZpY2F0aW9ucyBhbmQgdGhl aXIgYW50aWNpcGF0ZWQgY29tcGxldGlvbiBkYXRlcy4NCg0KKiBQdWJsaXNoLVN1YnNjcmliZSBC cm9rZXIgZm9yIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCk6IDxk cmFmdC1rb3N0ZXItY29yZS1jb2FwLXB1YnN1Yi0wND4NCiogQSBUQ1AgYW5kIFRMUyBUcmFuc3Bv cnQgZm9yIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCk6IDxkcmFm dC1pZXRmLWNvcmUtY29hcC10Y3AtdGxzLTAxPg0KKiBDb1JFIFJlc291cmNlIERpcmVjdG9yeTog PGRyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3RvcnktMDc+DQoqIEJsb2NrLXdpc2UgdHJh bnNmZXJzIGluIENvQVA6IDxkcmFmdC1pZXRmLWNvcmUtYmxvY2stMTk+DQoNCk91ciB0aW1lbGlu ZSBmb3IgY29tcGxldGlvbiBvZiBMV00yTSB2MS4xIGlzIERlYyAyMDE2Lg0KDQpXZSBhcmUgYXdh cmUgb2YgdGhlIG1pbGVzdG9uZXMgcGFnZSBvZiB0aGUgSUVURiB3b3JraW5nIGdyb3VwcyBhbmQg dGhlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBkYXRhdHJhY2tlciBidXQgaXQgaXMgbmV2ZXJ0aGVs ZXNzIGRpZmZpY3VsdCB0byBkZXRlcm1pbmUgYSBjb21wbGV0aW9uIGRhdGUuDQoNClBsZWFzZSBs ZXQgdXMga25vdyBpZiB0aGVyZSBpcyBhbnl0aGluZyB3ZSBjYW4gZG8gdG8gYWNjZWxlcmF0ZSB0 aGUgY29tcGxldGlvbiBvZiB0aGUgYWJvdmUtbWVudGlvbmVkIHNwZWNpZmljYXRpb25zLg0KDQpC ZXN0IFJlZ2FyZHMsIFBhZGh1DQpQcmluY2lwYWwgUHJvZHVjdCBNYW5hZ2VyLCBJbmR1c3RyeSBT dGFuZGFyZHMNCkN1c3RvbWVyIEV4cGVyaWVuY2UgTWFuYWdlbWVudCwgTk9LSUENCg0KMjB0aCBj ZW50dXJ5IG91ciBiZXN0IG1pbmRzIHdlbnQgdG8gd29yayBvbiBob3cgdG8gY29ucXVlciBuYXR1 cmUsIDIxc3QgY2VudHVyeSBvdXIgYmVzdCBtaW5kcyBhcmUgd29ya2luZyB0byByZXN0b3JlIGl0 DQoNClRoaXMgbWVzc2FnZSAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgY29udGFpbnMgY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciBhIHNwZWNpZmljIGluZGl2aWR1YWwg YW5kIHB1cnBvc2UsIGFuZCBpcyBwcm90ZWN0ZWQgYnkgbGF3LiAgSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgeW91IHNob3VsZCBkZWxldGUgdGhpcyBtZXNzYWdlLiAgQW55 IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIG1lc3NhZ2UsIG9y IHRoZSB0YWtpbmcgb2YgYW55IGFjdGlvbiBiYXNlZCBvbiBpdCwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCB3aXRob3V0IHRoZSBwcmlvciBjb25zZW50IG9mIGl0cyBhdXRob3IuDQo= --_000_30BE9EF04A9C48E6B158493E19C30D1Ealcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <139F6192A423FE48B895440512915E0F@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQXBwbGVHb3RoaWMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+RGVhciBDb1JFIFdvcmtpbmcgR3JvdXAgQ2hhaXJzLDwvZGl2Pg0KPGRp dj5IaSBhbGwsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFtIGNvLWNoYWlyIG9m IHRoZSBPTUEgRGV2aWNlIE1hbmFnZW1lbnQgd29ya2luZyBncm91cCwgd2hvIGRldmVsb3BzIHRo ZSBMV00yTSBzcGVjaWZpY2F0aW9uLiBXZSBhcmUgY3VycmVudGx5IGluIHRoZSBwcm9jZXNzIG9m IGRlZmluaW5nIHZlcnNpb24gMS4xIG9mIHRoZSBMV00yTSBwcm90b2NvbCBhbmQgd291bGQgbGlr ZSB0byByZS11c2UgYXMgbWFueSBJRVRGIHNwZWNpZmljYXRpb25zIGFzIHBvc3NpYmxlLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Rm9yIHRoaXMgcHVycG9zZSB3ZSBhcmUgc2Vla2lu ZyBmb3IgZnVydGhlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc3RhdHVzIG9mIHRoZSBmb2xsb3dp bmcgc3BlY2lmaWNhdGlvbnMgYW5kIHRoZWlyIGFudGljaXBhdGVkIGNvbXBsZXRpb24gZGF0ZXMu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4qIFB1Ymxpc2gtU3Vic2NyaWJlIEJyb2tl ciBmb3IgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKTogJmx0O2Ry YWZ0LWtvc3Rlci1jb3JlLWNvYXAtcHVic3ViLTA0Jmd0OzwvZGl2Pg0KPGRpdj4qIEEgVENQIGFu ZCBUTFMgVHJhbnNwb3J0IGZvciB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wg KENvQVApOiAmbHQ7ZHJhZnQtaWV0Zi1jb3JlLWNvYXAtdGNwLXRscy0wMSZndDs8L2Rpdj4NCjxk aXY+KiBDb1JFIFJlc291cmNlIERpcmVjdG9yeTogJmx0O2RyYWZ0LWlldGYtY29yZS1yZXNvdXJj ZS1kaXJlY3RvcnktMDcmZ3Q7PC9kaXY+DQo8ZGl2PiogQmxvY2std2lzZSB0cmFuc2ZlcnMgaW4g Q29BUDogJmx0O2RyYWZ0LWlldGYtY29yZS1ibG9jay0xOSZndDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pk91ciB0aW1lbGluZSBmb3IgY29tcGxldGlvbiBvZiBMV00yTSB2MS4xIGlz IERlYyAyMDE2LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+V2UgYXJlIGF3YXJlIG9m IHRoZSBtaWxlc3RvbmVzIHBhZ2Ugb2YgdGhlIElFVEYgd29ya2luZyBncm91cHMgYW5kIHRoZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgZGF0YXRyYWNrZXIgYnV0IGl0IGlzIG5ldmVydGhlbGVzcyBk aWZmaWN1bHQgdG8gZGV0ZXJtaW5lIGEgY29tcGxldGlvbiBkYXRlLiZuYnNwOzwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+UGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGlzIGFueXRo aW5nIHdlIGNhbiBkbyB0byBhY2NlbGVyYXRlIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBhYm92ZS1t ZW50aW9uZWQgc3BlY2lmaWNhdGlvbnMuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+QmVzdCBSZWdhcmRzLCBQYWRodTwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5QcmluY2lwYWwgUHJv ZHVjdCBNYW5hZ2VyLCBJbmR1c3RyeSBTdGFuZGFyZHM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+Q3VzdG9tZXIgRXhwZXJpZW5jZSBNYW5hZ2VtZW50 LCBOT0tJQTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJk OyI+MjB0aCBjZW50dXJ5IG91ciBiZXN0IG1pbmRzIHdlbnQgdG8gd29yayBvbiBob3cgdG8gY29u cXVlciBuYXR1cmUsIDIxc3QgY2VudHVyeSBvdXIgYmVzdCBtaW5kcyBhcmUgd29ya2luZyB0byBy ZXN0b3JlIGl0PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij5UaGlzIG1lc3NhZ2UgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIGNvbnRhaW5zIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgYSBzcGVjaWZpYyBpbmRpdmlkdWFs IGFuZCBwdXJwb3NlLCBhbmQgaXMgcHJvdGVjdGVkIGJ5IGxhdy4mbmJzcDsmbmJzcDtJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ugc2hvdWxkIGRlbGV0ZSB0aGlzIG1l c3NhZ2UuJm5ic3A7Jm5ic3A7QW55DQogZGlzY2xvc3VyZSwgY29weWluZywgb3IgZGlzdHJpYnV0 aW9uIG9mIHRoaXMgbWVzc2FnZSwgb3IgdGhlIHRha2luZyBvZiBhbnkgYWN0aW9uIGJhc2VkIG9u IGl0LCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIHdpdGhvdXQgdGhlIHByaW9yIGNvbnNlbnQgb2Yg aXRzIGF1dGhvci48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_30BE9EF04A9C48E6B158493E19C30D1Ealcatellucentcom_-- From nobody Tue Apr 19 05:45:27 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0212D881 for ; Tue, 19 Apr 2016 05:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXAtTMcnvf-R for ; Tue, 19 Apr 2016 05:45:23 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA5612D7E0 for ; Tue, 19 Apr 2016 05:45:23 -0700 (PDT) Received: from mfilter43-d.gandi.net (mfilter43-d.gandi.net [217.70.178.174]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9A52241C07D; Tue, 19 Apr 2016 14:45:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter43-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter43-d.gandi.net (mfilter43-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id y5SnL-IXVT4l; Tue, 19 Apr 2016 14:45:20 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id A925041C09E; Tue, 19 Apr 2016 14:45:19 +0200 (CEST) Message-ID: <5716285E.5020100@tzi.org> Date: Tue, 19 Apr 2016 14:45:18 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <57161AFB.5040804@gmx.net> In-Reply-To: <57161AFB.5040804@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Issue Tracking of Working Group Items X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:45:25 -0000 Hi Hannes, after an IETF it typically takes a while for people to come back up to speed, because of significant travel times, combined with a backlog of non-IETF issues waiting at home. Not all contributors are full time IETFers. That said, I do indeed request the respective authors to act on trackerizing the issues by the end of this week. Grüße, Carsten From nobody Tue Apr 19 05:49:53 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE512DBB7 for ; Tue, 19 Apr 2016 05:49:51 -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] 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 k21ZMveH12WA for ; Tue, 19 Apr 2016 05:49:45 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B546F12DB55 for ; Tue, 19 Apr 2016 05:49:45 -0700 (PDT) Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id BC1F2FB8CF; Tue, 19 Apr 2016 14:49:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id f73QLJiu8Wpx; Tue, 19 Apr 2016 14:49:42 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 0F526FB8DA; Tue, 19 Apr 2016 14:49:34 +0200 (CEST) Message-ID: <5716295D.7010204@tzi.org> Date: Tue, 19 Apr 2016 14:49:33 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <57161AFB.5040804@gmx.net> In-Reply-To: <57161AFB.5040804@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Issue Tracking of Working Group Items X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:49:51 -0000 Willst Du die Entscheidung zu #396 eintragen oder soll ich das tun? (#397 wird da auch gleich erledigt, aber das haken wir dann am besten mit -02 ab.) Grüße, Carsten Hannes Tschofenig wrote: > Hi all, > > at the last IETF meeting we talked about the open issues with the > working group items and identified various issues that need to be > tackled with high priority. > > The document editors wanted to add the open issues to the WG tracker. > > I have just looked at the tracker at > https://trac.tools.ietf.org/wg/core/trac/report/1 and, unfortunately, > nobody has added any issues. > > If we indeed want to complete many of the WG items by the Berlin IETF > meeting then we should at least add the open issues to the tracker > before we can resolve them one-by-one. > > It is not even clear to me who is in charge (editor) for each of the WG > documents. > > If there isn't even enough energy by the authors to identify the open > issues and to add them to the tracker then the group is in trouble and > IMHO should definitely not adopt new WG documents. > > Ciao > Hannes > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 19 05:56:18 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B0512DCC8 for ; Tue, 19 Apr 2016 05:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 j4dx7DUUMtep for ; Tue, 19 Apr 2016 05:56:16 -0700 (PDT) Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F9612DAFC for ; Tue, 19 Apr 2016 05:56:15 -0700 (PDT) X-ASG-Debug-ID: 1461070573-06daaa10861a2f0001-aa7cYp Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id nGuRIahgfWM8sqTG (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2016 08:56:14 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 08:56:13 -0400 From: "Rahman, Akbar" To: Carsten Bormann , Hannes Tschofenig Thread-Topic: [core] Issue Tracking of Working Group Items X-ASG-Orig-Subj: RE: [core] Issue Tracking of Working Group Items Thread-Index: AQHRmjFgn9ouE5jkqEe3HAdxpiHlVp+RgVIA//++k4A= Date: Tue, 19 Apr 2016 12:56:12 +0000 Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAAE871@NABESITE.InterDigital.com> References: <57161AFB.5040804@gmx.net> <5716285E.5020100@tzi.org> In-Reply-To: <5716285E.5020100@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.2.226] x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252] X-Barracuda-Start-Time: 1461070574 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 1136 X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Issue Tracking of Working Group Items X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:56:17 -0000 Hi Carsten/Hannes, For the HTTP-CoAP draft we did send an email shortly after the meeting aski= ng the WG list to confirm our decision at the meeting: https://www.ietf.org/mail-archive/web/core/current/msg07035.html So I think no tracker ticket is required for this (though we could add one = if you think it necessary). /Akbar -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, April 19, 2016 8:45 AM To: Hannes Tschofenig Cc: core@ietf.org WG Subject: Re: [core] Issue Tracking of Working Group Items Hi Hannes, after an IETF it typically takes a while for people to come back up to spee= d, because of significant travel times, combined with a backlog of non-IETF= issues waiting at home. Not all contributors are full time IETFers. That said, I do indeed request the respective authors to act on trackerizin= g the issues by the end of this week. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Apr 19 08:51:08 2016 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 43BB712EACF; Tue, 19 Apr 2016 08:51:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419155107.31496.55575.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 08:51:07 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Kathleen Moriarty's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 15:51:07 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Stephen that the draft could read better if text duplication was reduced. From nobody Tue Apr 19 12:52:55 2016 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 BCEFC12DDC2; Tue, 19 Apr 2016 12:52:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419195252.31492.31249.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 12:52:52 -0700 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-senml-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 19:52:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Media Types for Sensor Markup Language (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Filename : draft-ietf-core-senml-00.txt Pages : 33 Date : 2016-04-19 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-core-senml-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 20:55:50 2016 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 BB03A12E177; Tue, 19 Apr 2016 20:55:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420035547.31549.85944.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 20:55:47 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Suresh Krishnan's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 03:55:48 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is there a specific reason that the 4.08 response code is overloaded for use for two different kinds of issues? a) Mismatching Content-Format options in different blocks b) not all previous blocks are available at the server at the time of processing the final block of an atomic operation Section 7.1: Have you thought about how this text can be made actionable, especially in the case of atomic PUT or POST requests without maintaining state? If so, it would be good to elaborate here. "Wherever possible, servers should therefore minimize the opportunities to create state for untrusted sources, e.g. by using stateless approaches." From nobody Wed Apr 20 04:05:12 2016 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 70F1412E3F0; Wed, 20 Apr 2016 04:05:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 04:05:10 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-block-19=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 11:05:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-core-block-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is only a minor point, requesting to spell out implicit assumptions explicitly. However, I think it's important to address this before publication. It is not clear in the main part of the doc that this extension to does not change the message transmission method as specified in RFC7252 (Stop-and-wait retransmission). With my initial ready I assumed that this extension would allow the sending of back-to-back messages. Only by looking at the examples, it got clear to me that this is not the case. Further, this document does not say anything about reliability. Do block message need to be transmitted reliable (as Confirmable)? If not, this extension could still lead to back-to-back sending and then further guidance on congestion control would be needed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with others that reduncy makes the doc harder to read, especially regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and MUST in one section and combine the Usage guidance with the examples? Further, please also add a reference for ETag in section 2.4. From nobody Wed Apr 20 08:42:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2519F12B023 for ; Wed, 20 Apr 2016 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 Ov3Ug6bAFNp4 for ; Wed, 20 Apr 2016 08:42:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0679B12DF3C for ; Wed, 20 Apr 2016 08:37:54 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MDV5t-1ay7uK3FXR-00GolH; Wed, 20 Apr 2016 17:37:33 +0200 To: "Rahman, Akbar" , Carsten Bormann References: <57161AFB.5040804@gmx.net> <5716285E.5020100@tzi.org> <36F5869FE31AB24485E5E3222C288E1F5BAAE871@NABESITE.InterDigital.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5717A242.7000306@gmx.net> Date: Wed, 20 Apr 2016 17:37:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BAAE871@NABESITE.InterDigital.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="egN5VFDxmhMJbDMis1U26s7tIacgsh0TF" X-Provags-ID: V03:K0:furqkfpleVYhdpIKVLsnt1Ts+n6NXv3U9en5VE+09g1o4/OtlU/ UEBxZ9+8rcV/5nVqxx3XEMXqRKlfnq3yfmcO4nXD3rMpbxG6N7bzcPRncwjU6XJpIC6fPee 6CkOfF4yv00+UvEp4Js8Cqj7aeiOH/EPHKeZYqJj4qwnnqgZHmg/z9CXh6fffkkiPZ2KWgX WhB/UqNiix2nhuwQBuPXw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ma//N+BleZw=:uuezsHE/YoDtJIgz8kW4im JkzxK3WYv6BMN5JWsi5PI0eiybLuMTbtf6JJ4E8mDPh3bPVSCvkwtM5ARgWdRcPUDXQUKJJ+p rA5DHIaC/VY+CaQpytYs9QfHzzlqlgBzb2HQ18VbBTHk6R4VR/HM8sQyP5xAsHyNHoiVoRnwc qftxdS2FYZElhN0dzs8l+Aa4arCZFSlSIf43X9aXsxM+UaLwQ06t0dcftpo7mspA8A6ROnkwG g6EXI4TldQ2l6v7KdICnWZATDUE/eitvHSkrxA40jibbyy3lwIU0A+l8ePBGIBWroaRr+/0QN 6EMmZEt27ax3sRgvWId5SNNyOzUL9HZCyxkzuhSYEpA4XUHZAazPO6p4XHoXzYx/kHngQbU/K Xd+NjbnRIYSu2g1BQOcBSG4Cz8rKrwCzeIe6qpy9WwJVj7hbm9eDwCBGaYcSkvUKozgNYTC0q yLDlb/2jMckPUda2YvZf/kBLZIhcqTyMbJ7aIckEa/j/6fHkte8/GUZ0+52M6LCC8wI6+8mRM SBbIiEvhpSWflqFrpfaUo+wwT5nb8luoL9PpiKzQcPPfBkRryggtGawjiJ0GMpeelqqscsr/m oVXMHF4mZd68no8K0/aiTPOm0cm0tcFnRIvAPuzttgNrsLw3m5L/ymCXV9URnOt6Ui5ulsZQ9 Ij3a1MTM7dBKBS5q8P7rFmRMoknkVfhSJNcYOGpTaPY17qeeBDR4hNL1LLBaUsa8Dx7VqPY2f XAYblnwamkoA3nX/8izTU4bg/2jLThx5NmfOwyI5eXU+TpvvnvLOgZ/HBeY= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] Issue Tracking of Working Group Items X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:42:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --egN5VFDxmhMJbDMis1U26s7tIacgsh0TF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Akbar. I prefer to have issues added to make sure we know where we are with our work. Btw, are you the editor of the HTTP-CoAP document? It seems to me that you are at least the most active person on it (whereas some of your co-authors have disappeared from the scene already). Ciao Hannes On 04/19/2016 02:56 PM, Rahman, Akbar wrote: > Hi Carsten/Hannes, >=20 >=20 > For the HTTP-CoAP draft we did send an email shortly after the meeting = asking the WG list to confirm our decision at the meeting: >=20 > https://www.ietf.org/mail-archive/web/core/current/msg07035.html >=20 >=20 > So I think no tracker ticket is required for this (though we could add = one if you think it necessary). >=20 >=20 >=20 > /Akbar >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Tuesday, April 19, 2016 8:45 AM > To: Hannes Tschofenig > Cc: core@ietf.org WG > Subject: Re: [core] Issue Tracking of Working Group Items >=20 > Hi Hannes, >=20 > after an IETF it typically takes a while for people to come back up to = speed, because of significant travel times, combined with a backlog of no= n-IETF issues waiting at home. Not all contributors are full time IETFer= s. >=20 > That said, I do indeed request the respective authors to act on tracker= izing the issues by the end of this week. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --egN5VFDxmhMJbDMis1U26s7tIacgsh0TF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXF6JCAAoJEGhJURNOOiAtzN8H/3KmZYFUVcc3fR+KZ5IC9xpF uqZUMfG74qSJpXe+xJ2WLYV4eoLIS3r1JRZSJCmD1ToEQHfLt3BMRwKCG5iZd7/C /GV6mjZE1AQOa3kEF4jcXXzZeEp4pEQ7+0EyXkFiSGhpr9NVJsRWopaykQUFiVdZ hDYuaf5yXkflgvzZckZ/yHH+9G0wBbSysPvkXdzGmQ1CH8N/30GWcWKSRgJLd70L mR0m071LH6+4f0kxnZ4YL7o3cS+pV0Hc47gq2AyakpPuGxaIDeWDR882W7xmP9jo OSyspCW83X05v6Wos7iK/0TKPfCm8arC77IiHbJ7D6g78InLhM9w31cWGbsEp80= =N31/ -----END PGP SIGNATURE----- --egN5VFDxmhMJbDMis1U26s7tIacgsh0TF-- From nobody Wed Apr 20 08:42:47 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA22512DA61 for ; Wed, 20 Apr 2016 08:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, WEIRD_PORT=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 uMf9QSEUO1BS for ; Wed, 20 Apr 2016 08:42:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981B812E628 for ; Wed, 20 Apr 2016 08:39:54 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUkxk-1bG4Ko2f3k-00YDWI; Wed, 20 Apr 2016 17:39:34 +0200 To: "Rahman, Akbar" , Carsten Bormann , "core@ietf.org WG" References: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5717A2BA.3020404@gmx.net> Date: Wed, 20 Apr 2016 17:39:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qqg9q0L3oTnBka06gCHhS5IWHAXBpwRuv" X-Provags-ID: V03:K0:u2+f7c0uvH9IsTn7X0eIUSbpYHVNaVJEnvnyqeYyiu7V6DAck2o /Hcs1bxM/h8UShuWtE3Ue8Xn/dInFAnoBAj58SfSJWtnWeir8p/kC4oV78/qyfCEkgDiuBs uY78eOwU9wl96VLpYL+gy2KCj4gWYi8MRFZmzvMypAaXkjLz85x1jyUTSFiiktFg+uAF6fs 7PAM0vhyAv59Ttqj2GICQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:BiCRVasECZo=:8RHWIw5qaVsd5HqlLg7sDR CkdggThD2WdH9eE3x2O3waO4XJujmEBuaEiMYeopHkIF3e0RdsnP+unp0Sqbkj+ECBuqE+CiH Hw43l1iqkj9L4YLsPWKO8AVHatjgmkolmO4x4OyvmHCgQ4JENto99ZzqipW4KfxszYwwBDpDu 5k1jOe8FKtkSUXdHXMo0QzT4yAspgXGHPhLR/NzIspIwVULMBj6oPDlwFmcKj+3XYeMt+0XpW ORY53PDq6jWY5MXX1LxUReVecwfcck+REw7Iilj3B/rH4NX7swWCgvwfyXf9fIHw5QaAB33Z0 v4WTmNtjDvZmNsm1fEVBwppkrsZUB1afgH74T54RT8jtC8yt2V/uLTix0xTtVms9NqWmueW4C WnZceaczPAGcL2Z9oH6p9LJUz4spnChd7YdHU2L2Z7aE6O+8oaS+lcpkBLK8mqIIPHMX0G3oG 3guVIgBpxedrJYWnr9NQeL8ZUGN4JZ8Tondz3VjOKgKZfzMSLVQ4EEKJGCPr9vtCJynd/iM+X PNLY89FUrXta9xgXXiPsvClqoH/4EeIggGgxRWqqxoazBP/eQlaZp91YK9RXZ1hAyndcehhAS Yu5TLU6F7n6PnylBlaBChWpLBm2W4lJz64K9zoSxHBhfzXdjmajfQDKS9lLnkxGJuBcg7dG7b rFRxsQDc4pKdxIo/0dSJ8bAuXekuX1NxrxY3I8+jaYmvXBdj6FeGZ0ChzjQMNczjMeT0g1T9u 2ybHPs2JMh6DVhilaSVcgGJJNIBaKDG5ucjiJFsfrFuvD4PdEbnApkdx8AI= Archived-At: Subject: Re: [core] Comments on proposed changes to draft-ietf-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:42:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qqg9q0L3oTnBka06gCHhS5IWHAXBpwRuv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Akbar, changing the scope of the document to include forward and reverse proxy functionality, as discussed in BA, is fine for me. Ciao Hannes On 04/11/2016 10:27 PM, Rahman, Akbar wrote: > Hi All, >=20 >=20 > At IETF-95 (Buenos Aires) we discussed modifying draft-ietf-core-http-m= apping to: >=20 > Clarify that the scope of draft is primarily Reverse HC Proxy bu= t that it also covers generic protocol translation aspects that apply as = well to Forward and Interception HC Proxy > =E2=96=A0 e.g. Response status mapping & content format = mapping apply to all types of proxies >=20 >=20 > Specifically see pg. 70-71 of the F2F presentation slides that presents= the details of the proposed changes: >=20 > https://www.ietf.org/proceedings/95/slides/slides-95-core-0.pdf >=20 >=20 > We had good support during the F2F meeting to make these changes. Does= anyone have any issues with this approach? If you do please write back = to the list. If we have not received any comments by April 22 we will as= sume that this decision is supported by the WG and will proceed to make t= he changes so that we can start the new WGLC. >=20 >=20 >=20 > Thanks, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Saturday, April 09, 2016 10:00 AM > To: core@ietf.org WG > Subject: [core] Summary of second meeting at IETF95 >=20 > ... and here is my summary of the Friday results. >=20 > Again, please send in fixes and additions; the raw details are still at= the same site: http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core > Big thanks to the note takers! >=20 > On Friday: >=20 > * Handoff of the Baton: Barry Leiba gave his farewall as CoRE's > responsible AD; great applause of the WG. > * For the resource directory (RD) and related documents, we are aiming > at WGLC before July 1st so we can discuss the outcome in Berlin and > ship soon after. There are quite a few things to do, many of which > are on the editorial level (see slides, but also Akbar's "advanced > RD" document; we will not try to put mirror server/pubsub support in > the RD document now, though). The issues will managed on the WG > tracker. > * There was in-room consensus to adopt draft-vanderstok-core-etch-00 > as a WG document. This is needed to keep PATCH in the RD, but also > for the management work (below). To be verified on the mailing > list. > * core-links-json also is in the same cluster (WGLC before July 1st). > Hannes would like to see the RFC7390 parts separated out from the > RFC6690 part that we are about for RD. The TODOs in the document > need to be ticked off/trackerized. > * There will be a 2nd WGLC for core-http-mapping after the comments > are incorporated (-10). > * core-interfaces may have been adopted too early and requires a major > overhaul, separating out the more speculative material (some of > which is T2TRG material). It should be made very clear that this > describes one way of using CoAP (which has indeed been picked up in > various ways by other SDOs), not the prescribed way. Matthias will > help Michael to do the separation. > * The work on management of constrained devices has converged ("COMI > with COOL"). The yang-cbor draft is ready for an adoption call, but > not enough people had read it yet to do an in-room adoption check. > The other drafts will undergo merger/restructuring work based on > this week's discussions and should then become ready for adoption. > This work is explicitly covered by our charter (which also calls out > LWM2M management as a related approach that we will continue to > support as needed), and we will implicate NETMOD/NETCONF into every > step we are taking. The author team invites the WG to its bi-weekly > phone meetings (to be announced on core mailing list). > * The work on Object Security for COAP (OSCOAP) is progressing nicely. > A complete draft can be expected for Berlin. >=20 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Carsten Bormann wrote: >> Here is my summary of what we did on Tuesday. >> Fixes/additions welcome; details are in the draft minutes at >> http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-core >> >> On Tuesday: >> >> * Andrew indicated that he plans to step down as a WG chair and that >> the ADs are looking for a replacement. >> * As periodically, the AD is changing; this time from a graybeard >> (Barry) to a blackbeard (Alexey). >> * The chairs apologize for the infrequently updated milestones; fixing= >> them is up next. >> * draft-ietf-core-block=E2=80=9319 is in IESG Evaluation, telechat dat= e is >> 2016=E2=80=9304=E2=80=9321. >> * heads-up for new individual drafts: draft-kivinen-802-15-ie and >> draft-bormann-6lo-coap-802-15-ie. >> * CoAP over TCP received extensive discussion. Results (all to be >> confirmed on the mailing list): >> * #396: We revert the decision in Yokohama and go with alternative >> L3. Procedurally, the pain of this reversal is balanced by the >> reduced pain of not having to convince OCF to change their >> specification. Technically, L3 is more open to evolving ideas abo= ut >> message sizes. In any case, there is no intent to modify or >> revoke section 4.6 of RFC 7252 at this time. >> * We will need to examine the various proposals to add signaling to >> the TCP connection (settings, ping/pong, release/abort). >> Signaling messages (7.xx) is one possible mechanism for doing that= =2E >> * #387 (ALPN): We really need to make a decision here. >> * Websockets: For merging the websockets draft into the TCP/TLS WG >> document (with the websockets specific parts going to an >> appendix), the authors of both drafts will discuss the merge. >> * Multi-hop Security: Initial discussion of >> draft-hartke-core-e2e-security-reqs. >> * It is more well-defined what is being protected in a >> request-response that spans a proxy than with a pub-sub broker. >> * The current set of scenarios does not include the case that >> security services are being performed by the intermediary. >> Many such scenarios are conceivable; which ones have serious use >> cases? >> * Multicast (or, more generally, group communication) is not yet >> being considered. >> * Data Formats: WG to adopt SenML (to be confirmed on the mailing >> list). After a bit of Brownian motion, the WG is now happy with the= >> way the data is formatted in -06 (base record with data, zero or >> more records with more data). The addition of links in the data is >> to be done by registering a senml label in core-links-json >> ("reversing the arrow of dependency"). >> >> Friday meeting upcoming. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> >> >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --qqg9q0L3oTnBka06gCHhS5IWHAXBpwRuv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXF6K7AAoJEGhJURNOOiAtMoIH/jVhg7s20YG5KoOEevIjt0Mk 4oTvugwErTVE20cmQSUk4ptSUA4LHlCnHFynHIXTBU5gHyVyiwsiOcdCJlUb8Qtb e4NiwyEhRxkrKGLxOwcoGW6U7PJwDASLLEvAv7W63jp2jBCuQGxk5th8lS38cSLF hZl0CpC+0EpDoBWrUyrOHahuvvXFoGUPXcv6sNkNbg/Coq9iVCjXviTsNjKhbmHc Xw77iFApugdXuejI/jtXAEFo+HEekJjn0dSmnesmFOL9zIJvNuqzyP4qqdXdOHej RSCxn6rCG0bBr2P4HjGiBikOk/PYStMBJiBTdz8fT7XGpa7pBaKH0kHVlpg35+c= =akt2 -----END PGP SIGNATURE----- --qqg9q0L3oTnBka06gCHhS5IWHAXBpwRuv-- From nobody Wed Apr 20 08:44:20 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11312D7B2 for ; Wed, 20 Apr 2016 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 faHsFg1v9zp0 for ; Wed, 20 Apr 2016 08:44:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 73E5D12DB67 for ; Wed, 20 Apr 2016 08:42:02 -0700 (PDT) Received: from localhost ([::1]:49867 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1asuGP-0006i8-Ol; Wed, 20 Apr 2016 08:42:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net X-Trac-Project: core Date: Wed, 20 Apr 2016 15:42:01 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/396#comment:1 Message-ID: <080.1af82a8e43a3a4506536f87de8c1c3ca@trac.tools.ietf.org> References: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> X-Trac-Ticket-ID: 396 In-Reply-To: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:44:19 -0000 #396: L1 vs. L3 Encoding Approach Comment (by Hannes.Tschofenig@gmx.net): Based on the discussion at IETF#90, which was subsequently confirmed on the mailing list -- see https://www.ietf.org/mail- archive/web/core/current/msg07025.html, we will change our approach for length encoding from a fixed 16-bit length encoding to a variable 8/16/32 bit encoding instead (called alternative L3 in earlier draft versions). -- -------------------------------------+------------------------------------- Reporter: | Owner: Hannes.Tschofenig@gmx.net | hannes.tschofenig@gmx.net Type: other technical | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: core From nobody Wed Apr 20 08:50:44 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E712E338 for ; Wed, 20 Apr 2016 08:50:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20mFCu31_huS for ; Wed, 20 Apr 2016 08:50:41 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE4812E028 for ; Wed, 20 Apr 2016 08:50:40 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id e190so43706703lfe.0 for ; Wed, 20 Apr 2016 08:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jyw6Oae66Y4nf0fvpaiLmAnNBa6QP+JK6EeSAk3tdl8=; b=Xku88hM5Kcz/SBH/VPA/Dcz6EwI/2P45N+mnLeogUh1TlHuxvTZD6AYsNZJXjPTbf1 nReuL7y+ICj4BDI0pAHqLXGdVjhj4gPEkVxGElyXV1ESx1TOsdg1zArej4vfwBL3btZh JqgO7VlE4lNdzrRxoQktk/5E0LjY3DUgVSghtRKsJlyRFs9/uQy9H8uXJaDMP+YzmHgA jmfwEYYTWTxlin03lqKnCBRkNdgmZB0FOXAkMkpfGl4qIQy/nU0QtSCqtX/1kR6vPx9W FtMIWeEua5qyKdsdj/ZD9mkvrTQgrvdWCmXwCOEsLnaXZTcgWROX198oXBow9gBUdOBx Nfbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jyw6Oae66Y4nf0fvpaiLmAnNBa6QP+JK6EeSAk3tdl8=; b=Yb7iwypg61Zon6VOcODxvd9AyH9XuzkBQMofAKbVJQHnecsyeMuUrJL+HWzkTX1LZ/ IM91AJ8+RfbVVXaQL3iHiFyNTlKFVAtV61VaQS6xGfIJwbIJfGHhgIjlNETSh9DRHazo /a67t7hVk2NA7meWO1ZWyXnRlfPkyvAmw4k0eC8Po4ODFxF3JsRcz7nuOWnR+81jAZQb 4Na752vYzcdYy4hRVWMHPVSPK0egHfkLkuAGx8gLe8bZ1uu4+n4eGQjemTba0yOGvZxe HIEEk4oLm+T544fR1xICowTWUCmvZ3fzGaZeAyfTZY96htnlOPyuxdRAFyl73W3KRbV8 KAmw== X-Gm-Message-State: AOPr4FXvjiMhdzJDAaE3ke93m+IW6Us+7DIrIRDAkU7bcWT8L95oHl5CxdvVZx0DdiYwHMpIniyQBVwa2cBxSQ== MIME-Version: 1.0 X-Received: by 10.25.64.212 with SMTP id n203mr4325833lfa.62.1461167438701; Wed, 20 Apr 2016 08:50:38 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Wed, 20 Apr 2016 08:50:38 -0700 (PDT) In-Reply-To: <570A4583.2030100@tzi.org> References: <570A4583.2030100@tzi.org> Date: Wed, 20 Apr 2016 08:50:38 -0700 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113fc26a244b390530ec8eb9 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:50:42 -0000 --001a113fc26a244b390530ec8eb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am in favor of adoption. We plan to implement this draft for use with CoMI and possibly RESTCONF. Andy On Sun, Apr 10, 2016 at 5:22 AM, Carsten Bormann wrote: > In Buenos Aires, we discussed the adoption of > draft-veillette-core-yang-cbor-mapping-00 but not enough people had read > the document to go for an in-room consensus call. > > This is a two-week call for adoption of > draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. > Specifically, if you (1) support or (2) have an objection to this > decision, please speak up on the mailing list by 2016-04-24. > > Note that this work is explicitly covered by our charter, so discussions > of which WG should work on this are off-topic. > > As always, adoption of a document as a WG document is not a vote on > whether we already have reached last-call state; the intention is to > work on the WG document after adoption for a while to get it ready for > last call. If you want to combine your support/objection with technical > comments, this is certainly welcome so we can accelerate that process. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a113fc26a244b390530ec8eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am in favor of adoption.
We plan to implement this draft for use with CoMI
and possibly = RESTCONF.


Andy

=

On Sun, Apr= 10, 2016 at 5:22 AM, Carsten Bormann <cabo@tzi.org> wrote:
In Buenos Aires, we discussed the adoption of<= br> draft-veillette-core-yang-cbor-mapping-00 but not enough people had read the document to go for an in-room consensus call.

This is a two-week call for adoption of
draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE.
Specifically, if you (1) support or (2) have an objection to this
decision, please speak up on the mailing list by 2016-04-24.

Note that this work is explicitly covered by our charter, so discussions of which WG should work on this are off-topic.

As always, adoption of a document as a WG document is not a vote on
whether we already have reached last-call state; the intention is to
work on the WG document after adoption for a while to get it ready for
last call.=C2=A0 If you want to combine your support/objection with technic= al
comments, this is certainly welcome so we can accelerate that process.

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

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

--001a113fc26a244b390530ec8eb9-- From nobody Wed Apr 20 09:08:50 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A712DF21 for ; Wed, 20 Apr 2016 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 9pa4Tgfs2ezy for ; Wed, 20 Apr 2016 09:08:42 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0115.outbound.protection.outlook.com [104.47.2.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E10312D97B for ; Wed, 20 Apr 2016 09:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pDBuL7eBuLjoGtN6Lf90CAkjcLxykLhRZtVJvTO+V5w=; b=N4sSM+fMwnzduWPA5II3tW9PIQfInqI/EHNe6aDuQFlupIzKrUG+nP/kzPW+U9VU/3s2AC3JT9tpadz4u5b5VZ05LT3jrjj1NztsuXSXgBWXsw7ZUDZle8e4HjC3pJGAhYR58fuEPwLudCTl6ALLQ+Bb/kHJlCayp7f9YsbBVR4= Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1838.eurprd06.prod.outlook.com (10.165.237.156) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 16:08:38 +0000 Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 16:08:38 +0000 From: Somaraju Abhinav To: Andy Bierman , Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRkyOt4F+Ix0rEaEedjfMR6kWbt5+TEn0AgAAED2M= Date: Wed, 20 Apr 2016 16:08:38 +0000 Message-ID: References: <570A4583.2030100@tzi.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=tridonic.com; x-originating-ip: [132.245.226.21] x-ms-office365-filtering-correlation-id: 9d828d41-6517-4b09-1567-08d3693608cf x-microsoft-exchange-diagnostics: 1; VI1PR06MB1838; 5:xqDEliZw+U7L2N2Gn7lPWXyQzCKhV1V8NwsabmzYiG5FfpWJ6IRnmQmEYuGHp5BYzSDZKMXckX+ApIyfUpyldUQspqeRsFYqjAbzkNwN0YZ0qQWYKuu4V/dP5UPhD3wzS7X2g0MoSJ/+l1SehW/DftqRNEBfHkVQh8kei7wACLFN8w8Ur9pEVcJ8ctakJcTC; 24:XbFc9+79qUm/xMVXbP1Cbu8oRIKaYC5yfGYKwuub03DXwXZUyKL+b+8Eq8ugz17/SHBAgp1kvX6ip1dS+3OuvRTkSssx050I01pFkjAEcXs=; 7:0yKBJjLxEh4xW81UK88V+ix8niVDg11RiWbgu1im25thcEDRmuvtA6LFplGPumRH5K6in1VzT0pgfTVgaii3IdzxRKjKby0925NTCWf55vDQYoZqH95mjNHWWlwbCL80fYfHb6P/OTIERkbSbqP5rmXTHLh1eLwYpAXZbMLBJrWXHkp3jxxQUf3AxmhPYE52gdBzjsKwYNxHbF1OPM+lFmkbS8ffGScgkojcoauzikU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1838; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1838; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(3280700002)(9686002)(19580395003)(2906002)(19580405001)(3660700001)(16236675004)(10400500002)(5003600100002)(5001770100001)(81166005)(74316001)(76576001)(33656002)(50986999)(19625215002)(5890100001)(5008740100001)(3900700001)(66066001)(76176999)(189998001)(54356999)(1096002)(6116002)(102836003)(230783001)(229383001)(106116001)(1220700001)(4326007)(19627405001)(122556002)(11100500001)(19617315012)(5004730100002)(15975445007)(77096005)(87936001)(3846002)(586003)(2950100001)(86362001)(2900100001)(5002640100001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1838; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB18398FE5960297BE101C2339FC6D0VI1PR06MB1839eurp_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 16:08:38.4123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1838 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:08:45 -0000 --_000_VI1PR06MB18398FE5960297BE101C2339FC6D0VI1PR06MB1839eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgKGFzIGFuIGF1dGhvcikgYW0gaW4gZmF2b3VyIG9mIGFkb3B0aW9uLg0KDQoNCldl IHBsYW4gdG8gdXNlIFlhbmcgdG8gbW9kZWwgcmVzb3VyY2VzIGluIGxpZ2h0aW5nIGFuZCBidWls ZGluZyBhdXRvbWF0aW9uIGFwcGxpY2F0aW9ucyBhbmQgd2lsbCB1c2UgdGhlIFlhbmctQ2JvciBt YXBwaW5nIGRyYWZ0IHRvIHNwZWNpZnkgaG93IHRoZSBwYXlsb2FkIHdpbGwgYmUgZm9ybWF0dGVk IGluIENCT1IgaW5zdGVhZCBvZiB1c2luZyBKU09OL1hNTCBzY2hlbWEgZGVmaW5pdGlvbnMuDQoN Cg0KQWJoaW5hdg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBj b3JlIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gPGFu ZHlAeXVtYXdvcmtzLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgNTo1MCBQ TQ0KVG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJl OiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNi b3ItbWFwcGluZy0wMA0KDQpIaSwNCg0KSSBhbSBpbiBmYXZvciBvZiBhZG9wdGlvbi4NCldlIHBs YW4gdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQgZm9yIHVzZSB3aXRoIENvTUkNCmFuZCBwb3NzaWJs eSBSRVNUQ09ORi4NCg0KDQpBbmR5DQoNCg0KT24gU3VuLCBBcHIgMTAsIDIwMTYgYXQgNToyMiBB TSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdy b3RlOg0KSW4gQnVlbm9zIEFpcmVzLCB3ZSBkaXNjdXNzZWQgdGhlIGFkb3B0aW9uIG9mDQpkcmFm dC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBidXQgbm90IGVub3VnaCBwZW9w bGUgaGFkIHJlYWQNCnRoZSBkb2N1bWVudCB0byBnbyBmb3IgYW4gaW4tcm9vbSBjb25zZW5zdXMg Y2FsbC4NCg0KVGhpcyBpcyBhIHR3by13ZWVrIGNhbGwgZm9yIGFkb3B0aW9uIG9mDQpkcmFmdC12 ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBhcyBhIFdHIGRvY3VtZW50IG9mIENv UkUuDQpTcGVjaWZpY2FsbHksIGlmIHlvdSAoMSkgc3VwcG9ydCBvciAoMikgaGF2ZSBhbiBvYmpl Y3Rpb24gdG8gdGhpcw0KZGVjaXNpb24sIHBsZWFzZSBzcGVhayB1cCBvbiB0aGUgbWFpbGluZyBs aXN0IGJ5IDIwMTYtMDQtMjQuDQoNCk5vdGUgdGhhdCB0aGlzIHdvcmsgaXMgZXhwbGljaXRseSBj b3ZlcmVkIGJ5IG91ciBjaGFydGVyLCBzbyBkaXNjdXNzaW9ucw0Kb2Ygd2hpY2ggV0cgc2hvdWxk IHdvcmsgb24gdGhpcyBhcmUgb2ZmLXRvcGljLg0KDQpBcyBhbHdheXMsIGFkb3B0aW9uIG9mIGEg ZG9jdW1lbnQgYXMgYSBXRyBkb2N1bWVudCBpcyBub3QgYSB2b3RlIG9uDQp3aGV0aGVyIHdlIGFs cmVhZHkgaGF2ZSByZWFjaGVkIGxhc3QtY2FsbCBzdGF0ZTsgdGhlIGludGVudGlvbiBpcyB0bw0K d29yayBvbiB0aGUgV0cgZG9jdW1lbnQgYWZ0ZXIgYWRvcHRpb24gZm9yIGEgd2hpbGUgdG8gZ2V0 IGl0IHJlYWR5IGZvcg0KbGFzdCBjYWxsLiAgSWYgeW91IHdhbnQgdG8gY29tYmluZSB5b3VyIHN1 cHBvcnQvb2JqZWN0aW9uIHdpdGggdGVjaG5pY2FsDQpjb21tZW50cywgdGhpcyBpcyBjZXJ0YWlu bHkgd2VsY29tZSBzbyB3ZSBjYW4gYWNjZWxlcmF0ZSB0aGF0IHByb2Nlc3MuDQoNCkdyw7zDn2Us IENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250 ZW50cyBvZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg dG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBv ciB1c2VkIGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIElmIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBw bGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWls IGFuZCBhdHRhY2hlZCBkb2N1bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2Vu ZGVyIG5vciB0aGUgc2VuZGVyJ3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZv ciB2aXJ1c2VzIGFuZCBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3Igb3RoZXJ3 aXNlIGNoZWNrIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMuDQo= --_000_VI1PR06MB18398FE5960297BE101C2339FC6D0VI1PR06MB1839eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3Vu ZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMt c2VyaWY7Ij4NCjxwPkhpLDwvcD4NCjxwPkkgKGFzIGFuIGF1dGhvcikgYW0gaW4gZmF2b3VyIG9m IGFkb3B0aW9uLiZuYnNwOzwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPldlIHBsYW4gdG8gdXNlIFlh bmcgdG8gbW9kZWwgcmVzb3VyY2VzIGluIGxpZ2h0aW5nIGFuZCBidWlsZGluZyBhdXRvbWF0aW9u IGFwcGxpY2F0aW9ucyBhbmQgd2lsbCB1c2UgdGhlIFlhbmctQ2JvciBtYXBwaW5nIGRyYWZ0IHRv IHNwZWNpZnkgaG93IHRoZSBwYXlsb2FkIHdpbGwgYmUgZm9ybWF0dGVkIGluIENCT1IgaW5zdGVh ZCBvZiB1c2luZyBKU09OL1hNTCBzY2hlbWEgZGVmaW5pdGlvbnMuJm5ic3A7PC9wPg0KPHA+PGJy Pg0KPC9wPg0KPHA+QWJoaW5hdjwvcD4NCjxicj4NCjxicj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4NCjxociB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1i bG9jazsgd2lkdGg6OTglIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9u dCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQt c2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gY29yZSAmbHQ7Y29yZS1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgNTo1MCBQTTxicj4NCjxi PlRvOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uPGJyPg0KPGI+Q2M6PC9iPiBjb3JlQGlldGYub3JnIFdH PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFm dC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMDwvZm9udD4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSwNCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkkgYW0gaW4gZmF2b3Igb2YgYWRvcHRpb24uPC9kaXY+DQo8ZGl2PldlIHBsYW4g dG8gaW1wbGVtZW50IHRoaXMgZHJhZnQgZm9yIHVzZSB3aXRoIENvTUk8L2Rpdj4NCjxkaXY+YW5k IHBvc3NpYmx5IFJFU1RDT05GLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkFuZHk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU3Vu LCBBcHIgMTAsIDIwMTYgYXQgNToyMiBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxzcGFuIGRpcj0ibHRy Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2Fi b0B0emkub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQpJbiBCdWVub3MgQWlyZXMsIHdlIGRpc2N1c3Nl ZCB0aGUgYWRvcHRpb24gb2Y8YnI+DQpkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFw cGluZy0wMCBidXQgbm90IGVub3VnaCBwZW9wbGUgaGFkIHJlYWQ8YnI+DQp0aGUgZG9jdW1lbnQg dG8gZ28gZm9yIGFuIGluLXJvb20gY29uc2Vuc3VzIGNhbGwuPGJyPg0KPGJyPg0KVGhpcyBpcyBh IHR3by13ZWVrIGNhbGwgZm9yIGFkb3B0aW9uIG9mPGJyPg0KZHJhZnQtdmVpbGxldHRlLWNvcmUt eWFuZy1jYm9yLW1hcHBpbmctMDAgYXMgYSBXRyBkb2N1bWVudCBvZiBDb1JFLjxicj4NClNwZWNp ZmljYWxseSwgaWYgeW91ICgxKSBzdXBwb3J0IG9yICgyKSBoYXZlIGFuIG9iamVjdGlvbiB0byB0 aGlzPGJyPg0KZGVjaXNpb24sIHBsZWFzZSBzcGVhayB1cCBvbiB0aGUgbWFpbGluZyBsaXN0IGJ5 IDIwMTYtMDQtMjQuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoaXMgd29yayBpcyBleHBsaWNpdGx5 IGNvdmVyZWQgYnkgb3VyIGNoYXJ0ZXIsIHNvIGRpc2N1c3Npb25zPGJyPg0Kb2Ygd2hpY2ggV0cg c2hvdWxkIHdvcmsgb24gdGhpcyBhcmUgb2ZmLXRvcGljLjxicj4NCjxicj4NCkFzIGFsd2F5cywg YWRvcHRpb24gb2YgYSBkb2N1bWVudCBhcyBhIFdHIGRvY3VtZW50IGlzIG5vdCBhIHZvdGUgb248 YnI+DQp3aGV0aGVyIHdlIGFscmVhZHkgaGF2ZSByZWFjaGVkIGxhc3QtY2FsbCBzdGF0ZTsgdGhl IGludGVudGlvbiBpcyB0bzxicj4NCndvcmsgb24gdGhlIFdHIGRvY3VtZW50IGFmdGVyIGFkb3B0 aW9uIGZvciBhIHdoaWxlIHRvIGdldCBpdCByZWFkeSBmb3I8YnI+DQpsYXN0IGNhbGwuJm5ic3A7 IElmIHlvdSB3YW50IHRvIGNvbWJpbmUgeW91ciBzdXBwb3J0L29iamVjdGlvbiB3aXRoIHRlY2hu aWNhbDxicj4NCmNvbW1lbnRzLCB0aGlzIGlzIGNlcnRhaW5seSB3ZWxjb21lIHNvIHdlIGNhbiBh Y2NlbGVyYXRlIHRoYXQgcHJvY2Vzcy48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5j b3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29u dGVudHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8g b3IgdXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LiBJZg0KIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9y LCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1t YWlsIGFuZCBhdHRhY2hlZCBkb2N1bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUg c2VuZGVyIG5vciB0aGUgc2VuZGVyJ3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5 IGZvciB2aXJ1c2VzIGFuZCBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3INCiBv dGhlcndpc2UgY2hlY2sgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_VI1PR06MB18398FE5960297BE101C2339FC6D0VI1PR06MB1839eurp_-- From nobody Wed Apr 20 09:31:11 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426A412EA33 for ; Wed, 20 Apr 2016 09:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT2nrOmA2NSl for ; Wed, 20 Apr 2016 09:31:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970AE12EA2C for ; Wed, 20 Apr 2016 09:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10558; q=dns/txt; s=iport; t=1461169868; x=1462379468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i+1HVIK1EymX/JWmae22SwK+PX5Ep0jUWTQxLDcbjuo=; b=EBgru097kpo7PFl5/HPwQb2OnBSPg5m/C80HkS5kJWexbNEYbXEsQWQF maQFvHUqruCVnNfpGEMXnxCB5fHl4Ni75MwgobtUEQt0j3t4xi7hlxBJU RFU7JkuJCz0Ft+fRhL/hYJ8V2uIIUwZVX/4cfEpxDkNg2hGtvA+7o+ixJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAgCQrRdX/4cNJK1egmtNU30GtHVFh?= =?us-ascii?q?C0BDYFxFwEKhWwCHIErOBQBAQEBAQEBZSeEQQEBAQQBAQEaBgpBCxACAQYCEQQ?= =?us-ascii?q?BASgDAgICJQsUBgMIAgQBDQUIiCEOkC6dF5ENAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQSGIYRLhGwJgkqCVgWTHoRxAY4MgW2ETYMphTSPLAEeAQFCg2hsh0l+AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos; i="5.24,510,1454976000"; d="scan'208,217"; a="93628779" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2016 16:31:07 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3KGV7B5010737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Apr 2016 16:31:07 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Apr 2016 11:31:06 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 20 Apr 2016 11:31:06 -0500 From: "Pascal Thubert (pthubert)" To: Andy Bierman , Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRmxxveThlN9f0OEWsq8Ev1kGM6p+TDUCg Date: Wed, 20 Apr 2016 16:31:04 +0000 Deferred-Delivery: Wed, 20 Apr 2016 16:30:13 +0000 Message-ID: References: <570A4583.2030100@tzi.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/alternative; boundary="_000_cec93c27a3d9492bb97bc11ad8e32b95XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 16:31:10 -0000 --_000_cec93c27a3d9492bb97bc11ad8e32b95XCHRCD001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIGEgc3RlcCBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0K DQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QW5keSBCaWVybWFuDQpTZW50OiBtZXJjcmVkaSAyMCBhdnJpbCAyMDE2IDE3OjUxDQpUbzogQ2Fy c3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12 ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMA0KDQpIaSwNCg0KSSBhbSBpbiBmYXZv ciBvZiBhZG9wdGlvbi4NCldlIHBsYW4gdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQgZm9yIHVzZSB3 aXRoIENvTUkNCmFuZCBwb3NzaWJseSBSRVNUQ09ORi4NCg0KDQpBbmR5DQoNCg0KT24gU3VuLCBB cHIgMTAsIDIwMTYgYXQgNToyMiBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp bHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KSW4gQnVlbm9zIEFpcmVzLCB3ZSBkaXNjdXNzZWQg dGhlIGFkb3B0aW9uIG9mDQpkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0w MCBidXQgbm90IGVub3VnaCBwZW9wbGUgaGFkIHJlYWQNCnRoZSBkb2N1bWVudCB0byBnbyBmb3Ig YW4gaW4tcm9vbSBjb25zZW5zdXMgY2FsbC4NCg0KVGhpcyBpcyBhIHR3by13ZWVrIGNhbGwgZm9y IGFkb3B0aW9uIG9mDQpkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBh cyBhIFdHIGRvY3VtZW50IG9mIENvUkUuDQpTcGVjaWZpY2FsbHksIGlmIHlvdSAoMSkgc3VwcG9y dCBvciAoMikgaGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhpcw0KZGVjaXNpb24sIHBsZWFzZSBzcGVh ayB1cCBvbiB0aGUgbWFpbGluZyBsaXN0IGJ5IDIwMTYtMDQtMjQuDQoNCk5vdGUgdGhhdCB0aGlz IHdvcmsgaXMgZXhwbGljaXRseSBjb3ZlcmVkIGJ5IG91ciBjaGFydGVyLCBzbyBkaXNjdXNzaW9u cw0Kb2Ygd2hpY2ggV0cgc2hvdWxkIHdvcmsgb24gdGhpcyBhcmUgb2ZmLXRvcGljLg0KDQpBcyBh bHdheXMsIGFkb3B0aW9uIG9mIGEgZG9jdW1lbnQgYXMgYSBXRyBkb2N1bWVudCBpcyBub3QgYSB2 b3RlIG9uDQp3aGV0aGVyIHdlIGFscmVhZHkgaGF2ZSByZWFjaGVkIGxhc3QtY2FsbCBzdGF0ZTsg dGhlIGludGVudGlvbiBpcyB0bw0Kd29yayBvbiB0aGUgV0cgZG9jdW1lbnQgYWZ0ZXIgYWRvcHRp b24gZm9yIGEgd2hpbGUgdG8gZ2V0IGl0IHJlYWR5IGZvcg0KbGFzdCBjYWxsLiAgSWYgeW91IHdh bnQgdG8gY29tYmluZSB5b3VyIHN1cHBvcnQvb2JqZWN0aW9uIHdpdGggdGVjaG5pY2FsDQpjb21t ZW50cywgdGhpcyBpcyBjZXJ0YWlubHkgd2VsY29tZSBzbyB3ZSBjYW4gYWNjZWxlcmF0ZSB0aGF0 IHByb2Nlc3MuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3Jn PG1haWx0bzpjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3JlDQoNCg== --_000_cec93c27a3d9492bb97bc11ad8e32b95XCHRCD001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mIzQzOzEsIGEgc3RlcCBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IG1lcmNyZWRp IDIwIGF2cmlsIDIwMTYgMTc6NTE8YnI+DQo8Yj5Ubzo8L2I+IENhcnN0ZW4gQm9ybWFubiAmbHQ7 Y2Fib0B0emkub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29y ZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSA8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3lt Ym9sJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBX RyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gaW4gZmF2 b3Igb2YgYWRvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBwbGFuIHRvIGltcGxlbWVudCB0aGlzIGRyYWZ0IGZvciB1c2Ugd2l0aCBD b01JPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h bmQgcG9zc2libHkgUkVTVENPTkYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDU6MjIgQU0s IENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIEJ1ZW5vcyBBaXJlcywgd2UgZGlzY3Vz c2VkIHRoZSBhZG9wdGlvbiBvZjxicj4NCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1t YXBwaW5nLTAwIGJ1dCBub3QgZW5vdWdoIHBlb3BsZSBoYWQgcmVhZDxicj4NCnRoZSBkb2N1bWVu dCB0byBnbyBmb3IgYW4gaW4tcm9vbSBjb25zZW5zdXMgY2FsbC48YnI+DQo8YnI+DQpUaGlzIGlz IGEgdHdvLXdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb2Y8YnI+DQpkcmFmdC12ZWlsbGV0dGUtY29y ZS15YW5nLWNib3ItbWFwcGluZy0wMCBhcyBhIFdHIGRvY3VtZW50IG9mIENvUkUuPGJyPg0KU3Bl Y2lmaWNhbGx5LCBpZiB5b3UgKDEpIHN1cHBvcnQgb3IgKDIpIGhhdmUgYW4gb2JqZWN0aW9uIHRv IHRoaXM8YnI+DQpkZWNpc2lvbiwgcGxlYXNlIHNwZWFrIHVwIG9uIHRoZSBtYWlsaW5nIGxpc3Qg YnkgMjAxNi0wNC0yNC48YnI+DQo8YnI+DQpOb3RlIHRoYXQgdGhpcyB3b3JrIGlzIGV4cGxpY2l0 bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciwgc28gZGlzY3Vzc2lvbnM8YnI+DQpvZiB3aGljaCBX RyBzaG91bGQgd29yayBvbiB0aGlzIGFyZSBvZmYtdG9waWMuPGJyPg0KPGJyPg0KQXMgYWx3YXlz LCBhZG9wdGlvbiBvZiBhIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQgaXMgbm90IGEgdm90ZSBv bjxicj4NCndoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFzdC1jYWxsIHN0YXRlOyB0 aGUgaW50ZW50aW9uIGlzIHRvPGJyPg0Kd29yayBvbiB0aGUgV0cgZG9jdW1lbnQgYWZ0ZXIgYWRv cHRpb24gZm9yIGEgd2hpbGUgdG8gZ2V0IGl0IHJlYWR5IGZvcjxicj4NCmxhc3QgY2FsbC4mbmJz cDsgSWYgeW91IHdhbnQgdG8gY29tYmluZSB5b3VyIHN1cHBvcnQvb2JqZWN0aW9uIHdpdGggdGVj aG5pY2FsPGJyPg0KY29tbWVudHMsIHRoaXMgaXMgY2VydGFpbmx5IHdlbGNvbWUgc28gd2UgY2Fu IGFjY2VsZXJhdGUgdGhhdCBwcm9jZXNzLjxicj4NCjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmci PmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cec93c27a3d9492bb97bc11ad8e32b95XCHRCD001ciscocom_-- From nobody Wed Apr 20 10:43:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A338612E213 for ; Wed, 20 Apr 2016 10:43:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmpkcGuo464O for ; Wed, 20 Apr 2016 10:43:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr650115.outbound.protection.outlook.com [40.107.65.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1DA12DF87 for ; Wed, 20 Apr 2016 10:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5dJYvVM0wRUqTEavJ4ZiBilWfELEscJgtfExITQ8lFg=; b=NNm9kCT/qbCPgTNytnvaRfE+pk/LOijgtZFFVUgQGGi750j8om1UTtvAqjIFJV+jsQDBpdc2sYeb5vZWk2GmOpKyCS9JLEe/jS+TGPLnIHssL8WYGjs6wroQOeSQFpMdNH9s84GPCUK4QjvvEvwmV84nmAWfKhaCmmIQBnXxPYU= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 17:43:35 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0466.023; Wed, 20 Apr 2016 17:43:35 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRkyOt8k0bOhfeX0GvA3ed8jYnhJ+TEn0AgAALTACAABQYEA== Date: Wed, 20 Apr 2016 17:43:35 +0000 Message-ID: References: <570A4583.2030100@tzi.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 1200bc48-f8b9-454e-125f-08d369434c84 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:0s4iGnxm5LWmkSJOjGx7TsNMFR3iM9BvYuG0a3Uh+olyOjtdLKtC8gUTaNwV7HRGAxyryqGvMF7btUMYjpQ0nkLWmPBmFqlBqoUoaXQM8GBKxrSlfEiQiS/mnaPfVJp1xw0UcROx+dJGgB0h8Xc7bXY96P+qLdIEVFpmPB73qFHCQbL9m6w7OfbWXH1P+JBF; 24:t6/4kTS8yEfcYUvsT1wQ8UKnqy7+MvHoe37bpEfVsn37E/o/q2z6xTkA3n860kEpM7F9SMG+i9bDUJuvh0xxJTx4PktQOUQ1oMDTK3ZiJsE=; 7:QzmVJJrA7qPLkenaxUjALlzkCGzKVwgpiQJYvXC7DvVAChZvNscmNlll4uSrpPjY60S8Mf10kcGbnZfcLW5j22HN1wczibUsaOGwykEaokKskZKfj9gOE9Yw4ZjdFCh0grl7fiCjswx/f9Syq0PUVzsCjKzEArwlnoZZKK6kSwzNZCoCfAc1r+qgjXYVvnmR4zW71eq9iBf8OXalqcrMt9Z/ssLUM6pAEKjWUMsDEcI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(2906002)(9686002)(5008740100001)(92566002)(66066001)(19580405001)(19580395003)(81166005)(19617315012)(10400500002)(86362001)(5004730100002)(11100500001)(87936001)(5002640100001)(106116001)(99286002)(229383001)(19625215002)(33656002)(5003600100002)(16236675004)(74316001)(50986999)(76176999)(54356999)(230783001)(790700001)(19300405004)(4326007)(102836003)(6116002)(586003)(122556002)(2900100001)(3660700001)(77096005)(15975445007)(2950100001)(1096002)(1220700001)(3280700002)(3846002)(189998001)(110136002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763D2F611FA04EDE1DC6438FE6D0BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 17:43:35.4164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 17:43:41 -0000 --_000_BLUPR06MB1763D2F611FA04EDE1DC6438FE6D0BLUPR06MB1763namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgdGhlIGF1dGhvciwgaXQncyBhbiBvYnZpb3VzICsxLg0KDQpBcyBhIG1lbWJlciBvZiB0aGUg WmlnQmVlIE5BTiB3b3JraW5nIGdyb3VwIGFuZCB0aGUgcGVyc29uIGluIGNoYXJnZSBvZiByZWNv bW1lbmRpbmcgYSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yIGl0LCBpdCdzIGltcG9y dGFudCB0byBzdGFydCBzZWVpbmcgcHJvZ3Jlc3MgaW4gdGhpcyBnb2FsIG9mIGJyaW5naW5nIHRo ZSBJRVRGIG5ldHdvcmsgbWFuYWdlbWVudCBhcHByb2FjaCBiYXNlZCBvbiBZQU5HIHRvIHRoZSB3 b3JsZCBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gUHJvY2VlZGluZyBpbiBh IHRpbWVseSBtYW5uZXIgaXMgaW1wb3J0YW50IHRvIGdldCB0aGlzIHByb3RvY29sIGluIHRpbWUg Zm9yIGFkb3B0aW9uIGJ5IHRoaXMgb3JnYW5pemF0aW9uLiBUaGlzIGRyYWZ0IHJlcHJlc2VudHMg YSBmaXJzdCBidWlsZGluZyBibG9jayBhbmQgYSBzaWduaWZpY2FudCBzdGVwIGluIHRoaXMgZGly ZWN0aW9uLg0KDQpUaGUgbWFwcGluZyBwcm9wb3NlZCBieSB0aGlzIGRyYWZ0IGlzIGZsZXhpYmxl IGVub3VnaCB0byBiZSB1c2VkIGluIGRpZmZlcmVudCBzY2VuYXJpb3MuDQoNCi0gVGhpcyBtYXBw aW5nIHN1cHBvcnRzIG5hbWVzIHdoaWNoIGFsbG93cyBpdHMgdXNlIGluIFJFU0NPTkYgdG8gc3Vw cG9ydCBDQk9SIHNlcmlhbGl6YXRpb24NCi0gVGhpcyBtYXBwaW5nIHN1cHBvcnRzIGhhc2hlcyB3 aGljaCBhbGxvd3MgaXRzIHVzZSBieSB0aGUgQ29NSSBSRVNUIEFQSQ0KLSBUaGlzIG1hcHBpbmcg c3VwcG9ydHMgU0lEcyB3aGljaCBhbGxvd3MgaXRzIHVzZSBieSB0aGUgQ29PTCBSRVNUIEFQSQ0K DQpUaGUgbWFwcGluZyBwcm9wb3NlZCBieSB0aGlzIGRyYWZ0IGlzIGV4dHJlbWVseSBlZmZpY2ll bnQgd2hpY2ggbWFrZSBpdCBhcHBsaWNhYmxlIHRvIHRoZSBtb3N0IGNvbnN0cmFpbmVkIG5ldHdv cmtzIHN1Y2ggYXMgdGhvc2UgdGFyZ2V0ZWQgYnkgTFBXQU4uDQoNCkZpbmFsbHksIHRoaXMgd29y a3MgaXMgYWxzbyBvZiBpbnRlcmVzdCBmb3IgdGhlIDZUaVNDSCBncm91cCBhcyBhIHBvc3NpYmxl IHNvbHV0aW9uIGZvciBOZXR3b3JrIE1hbmFnZW1lbnQgRW50aXR5IChOTUUpIGFuZCBQYXRoIENv bXB1dGF0aW9uIEVsZW1lbnQgKFBDRSkgaW50ZWdyYXRpb24uDQoNClJlZ2FyZHMsDQpNaWNoZWwg VmVpbGxldHRlDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQpTZW50OiBBcHJpbC0yMC0xNiAx MjozMSBQTQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgQ2Fyc3RlbiBC b3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogY29yZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0 dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMA0KDQorMSwgYSBzdGVwIGluIHRoZSByaWdodCBk aXJlY3Rpb24uDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3Jl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IG1lcmNy ZWRpIDIwIGF2cmlsIDIwMTYgMTc6NTENClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9y ZzxtYWlsdG86Y2Fib0B0emkub3JnPj4NCkNjOiBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPiBXRyA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSZTogW2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNvcmUteWFu Zy1jYm9yLW1hcHBpbmctMDANCg0KSGksDQoNCkkgYW0gaW4gZmF2b3Igb2YgYWRvcHRpb24uDQpX ZSBwbGFuIHRvIGltcGxlbWVudCB0aGlzIGRyYWZ0IGZvciB1c2Ugd2l0aCBDb01JDQphbmQgcG9z c2libHkgUkVTVENPTkYuDQoNCg0KQW5keQ0KDQoNCk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDU6 MjIgQU0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+ PiB3cm90ZToNCkluIEJ1ZW5vcyBBaXJlcywgd2UgZGlzY3Vzc2VkIHRoZSBhZG9wdGlvbiBvZg0K ZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYnV0IG5vdCBlbm91Z2gg cGVvcGxlIGhhZCByZWFkDQp0aGUgZG9jdW1lbnQgdG8gZ28gZm9yIGFuIGluLXJvb20gY29uc2Vu c3VzIGNhbGwuDQoNClRoaXMgaXMgYSB0d28td2VlayBjYWxsIGZvciBhZG9wdGlvbiBvZg0KZHJh ZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYXMgYSBXRyBkb2N1bWVudCBv ZiBDb1JFLg0KU3BlY2lmaWNhbGx5LCBpZiB5b3UgKDEpIHN1cHBvcnQgb3IgKDIpIGhhdmUgYW4g b2JqZWN0aW9uIHRvIHRoaXMNCmRlY2lzaW9uLCBwbGVhc2Ugc3BlYWsgdXAgb24gdGhlIG1haWxp bmcgbGlzdCBieSAyMDE2LTA0LTI0Lg0KDQpOb3RlIHRoYXQgdGhpcyB3b3JrIGlzIGV4cGxpY2l0 bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciwgc28gZGlzY3Vzc2lvbnMNCm9mIHdoaWNoIFdHIHNo b3VsZCB3b3JrIG9uIHRoaXMgYXJlIG9mZi10b3BpYy4NCg0KQXMgYWx3YXlzLCBhZG9wdGlvbiBv ZiBhIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQgaXMgbm90IGEgdm90ZSBvbg0Kd2hldGhlciB3 ZSBhbHJlYWR5IGhhdmUgcmVhY2hlZCBsYXN0LWNhbGwgc3RhdGU7IHRoZSBpbnRlbnRpb24gaXMg dG8NCndvcmsgb24gdGhlIFdHIGRvY3VtZW50IGFmdGVyIGFkb3B0aW9uIGZvciBhIHdoaWxlIHRv IGdldCBpdCByZWFkeSBmb3INCmxhc3QgY2FsbC4gIElmIHlvdSB3YW50IHRvIGNvbWJpbmUgeW91 ciBzdXBwb3J0L29iamVjdGlvbiB3aXRoIHRlY2huaWNhbA0KY29tbWVudHMsIHRoaXMgaXMgY2Vy dGFpbmx5IHdlbGNvbWUgc28gd2UgY2FuIGFjY2VsZXJhdGUgdGhhdCBwcm9jZXNzLg0KDQpHcsO8 w59lLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo= --_000_BLUPR06MB1763D2F611FA04EDE1DC6438FE6D0BLUPR06MB1763namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3ltYm9sIjsNCglwYW5v c2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5BcyB0aGUgYXV0aG9yLCBpdCdzIGFuIG9idmlvdXMgJiM0MzsxLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgYSBtZW1iZXIgb2YgdGhlIFppZ0JlZSBOQU4g d29ya2luZyBncm91cCBhbmQgdGhlIHBlcnNvbiBpbiBjaGFyZ2Ugb2YgcmVjb21tZW5kaW5nIGEg bmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29sIGZvciBpdCwgaXQncyBpbXBvcnRhbnQNCiB0byBz dGFydCBzZWVpbmcgcHJvZ3Jlc3MgaW4gdGhpcyBnb2FsIG9mIGJyaW5naW5nIHRoZSBJRVRGIG5l dHdvcmsgbWFuYWdlbWVudCBhcHByb2FjaCBiYXNlZCBvbiBZQU5HIHRvIHRoZSB3b3JsZCBvZiBj b25zdHJhaW5lZCBkZXZpY2VzIGFuZCBuZXR3b3Jrcy4gUHJvY2VlZGluZyBpbiBhIHRpbWVseSBt YW5uZXIgaXMgaW1wb3J0YW50IHRvIGdldCB0aGlzIHByb3RvY29sIGluIHRpbWUgZm9yIGFkb3B0 aW9uIGJ5IHRoaXMgb3JnYW5pemF0aW9uLg0KIFRoaXMgZHJhZnQgcmVwcmVzZW50cyBhIGZpcnN0 IGJ1aWxkaW5nIGJsb2NrIGFuZCBhIHNpZ25pZmljYW50IHN0ZXAgaW4gdGhpcyBkaXJlY3Rpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgbWFwcGluZyBwcm9w b3NlZCBieSB0aGlzIGRyYWZ0IGlzIGZsZXhpYmxlIGVub3VnaCB0byBiZSB1c2VkIGluIGRpZmZl cmVudCBzY2VuYXJpb3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4t IFRoaXMgbWFwcGluZyBzdXBwb3J0cyBuYW1lcyB3aGljaCBhbGxvd3MgaXRzIHVzZSBpbiBSRVND T05GIHRvIHN1cHBvcnQgQ0JPUiBzZXJpYWxpemF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0gVGhpcyBtYXBwaW5nIHN1cHBvcnRzIGhhc2hlcyB3aGlj aCBhbGxvd3MgaXRzIHVzZSBieSB0aGUgQ29NSSBSRVNUIEFQSTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tIFRoaXMgbWFwcGluZyBzdXBwb3J0cyBTSURzIHdo aWNoIGFsbG93cyBpdHMgdXNlIGJ5IHRoZSBDb09MIFJFU1QgQVBJPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgbWFwcGluZyBwcm9wb3NlZCBieSB0aGlzIGRyYWZ0 IGlzIGV4dHJlbWVseSBlZmZpY2llbnQgd2hpY2ggbWFrZSBpdCBhcHBsaWNhYmxlIHRvIHRoZSBt b3N0IGNvbnN0cmFpbmVkIG5ldHdvcmtzIHN1Y2ggYXMgdGhvc2UgdGFyZ2V0ZWQNCiBieSBMUFdB Ti48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZpbmFsbHksIHRoaXMg d29ya3MgaXMgYWxzbyBvZiBpbnRlcmVzdCBmb3IgdGhlIDZUaVNDSCBncm91cCBhcyBhIHBvc3Np YmxlIHNvbHV0aW9uIGZvciBOZXR3b3JrIE1hbmFnZW1lbnQgRW50aXR5IChOTUUpIGFuZCBQYXRo IENvbXB1dGF0aW9uDQogRWxlbWVudCAoUENFKSBpbnRlZ3JhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hlbCBWZWlsbGV0dGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTxicj4NCjxiPlNl bnQ6PC9iPiBBcHJpbC0yMC0xNiAxMjozMSBQTTxicj4NCjxiPlRvOjwvYj4gQW5keSBCaWVybWFu ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7OyBDYXJzdGVuIEJvcm1hbm4gJmx0O2NhYm9AdHpp Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGNvcmVAaWV0Zi5vcmcgV0cgJmx0O2NvcmVAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSBTeW1ib2wmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5n LWNib3ItbWFwcGluZy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+JiM0Mzsx LCBhIHN0ZXAgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Q YXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBj b3JlIFs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y29yZS1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJy Pg0KPGI+U2VudDo8L2I+IG1lcmNyZWRpIDIwIGF2cmlsIDIwMTYgMTc6NTE8YnI+DQo8Yj5Ubzo8 L2I+IENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fi b0B0emkub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjb3JlQGll dGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0 Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Nv cmVdIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4Mjc2 Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gV0cgYWRvcHRpb24gb2YgZHJh ZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SSBhbSBpbiBmYXZvciBvZiBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+V2UgcGxhbiB0byBpbXBsZW1lbnQgdGhpcyBkcmFmdCBmb3IgdXNlIHdpdGggQ29NSTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5hbmQgcG9zc2libHkgUkVTVENPTkYuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDU6MjIg QU0sIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIEJ1ZW5vcyBBaXJlcywg d2UgZGlzY3Vzc2VkIHRoZSBhZG9wdGlvbiBvZjxicj4NCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlh bmctY2Jvci1tYXBwaW5nLTAwIGJ1dCBub3QgZW5vdWdoIHBlb3BsZSBoYWQgcmVhZDxicj4NCnRo ZSBkb2N1bWVudCB0byBnbyBmb3IgYW4gaW4tcm9vbSBjb25zZW5zdXMgY2FsbC48YnI+DQo8YnI+ DQpUaGlzIGlzIGEgdHdvLXdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb2Y8YnI+DQpkcmFmdC12ZWls bGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBhcyBhIFdHIGRvY3VtZW50IG9mIENvUkUu PGJyPg0KU3BlY2lmaWNhbGx5LCBpZiB5b3UgKDEpIHN1cHBvcnQgb3IgKDIpIGhhdmUgYW4gb2Jq ZWN0aW9uIHRvIHRoaXM8YnI+DQpkZWNpc2lvbiwgcGxlYXNlIHNwZWFrIHVwIG9uIHRoZSBtYWls aW5nIGxpc3QgYnkgMjAxNi0wNC0yNC48YnI+DQo8YnI+DQpOb3RlIHRoYXQgdGhpcyB3b3JrIGlz IGV4cGxpY2l0bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciwgc28gZGlzY3Vzc2lvbnM8YnI+DQpv ZiB3aGljaCBXRyBzaG91bGQgd29yayBvbiB0aGlzIGFyZSBvZmYtdG9waWMuPGJyPg0KPGJyPg0K QXMgYWx3YXlzLCBhZG9wdGlvbiBvZiBhIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQgaXMgbm90 IGEgdm90ZSBvbjxicj4NCndoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFzdC1jYWxs IHN0YXRlOyB0aGUgaW50ZW50aW9uIGlzIHRvPGJyPg0Kd29yayBvbiB0aGUgV0cgZG9jdW1lbnQg YWZ0ZXIgYWRvcHRpb24gZm9yIGEgd2hpbGUgdG8gZ2V0IGl0IHJlYWR5IGZvcjxicj4NCmxhc3Qg Y2FsbC4mbmJzcDsgSWYgeW91IHdhbnQgdG8gY29tYmluZSB5b3VyIHN1cHBvcnQvb2JqZWN0aW9u IHdpdGggdGVjaG5pY2FsPGJyPg0KY29tbWVudHMsIHRoaXMgaXMgY2VydGFpbmx5IHdlbGNvbWUg c28gd2UgY2FuIGFjY2VsZXJhdGUgdGhhdCBwcm9jZXNzLjxicj4NCjxicj4NCkdyw7zDn2UsIENh cnN0ZW48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVA aWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR06MB1763D2F611FA04EDE1DC6438FE6D0BLUPR06MB1763namp_-- From nobody Wed Apr 20 12:34:24 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425B412DBA1 for ; Wed, 20 Apr 2016 12:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.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 IbWT44tLb5Uf for ; Wed, 20 Apr 2016 12:34:21 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44F912D9F7 for ; Wed, 20 Apr 2016 12:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=LandisGyr.onmicrosoft.com; s=selector1-landisgyr-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eUWk2RtFLZc7VVaNlc9UvZdO42tVOavjjWk8fNyaVvU=; b=eUroz63iiMmuZMhjWkDd/N8stFU/MOwBnh12GJr/oRZIAa15MA4KhkN0iaQoVoDbQJy9mIhVq3AAe13bc/NfbO2lok7vu9QerbWZkjfQ+pHtTr53XBDbQLKixo+cP6hJYuawliTOQ9FLmfMcjW8Y+AQeXnZVRLj2x5tSsQ7bVUY= Received: from VI1PR01MB1823.eurprd01.prod.exchangelabs.com (10.166.40.21) by VI1PR01MB1823.eurprd01.prod.exchangelabs.com (10.166.40.21) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 19:34:04 +0000 Received: from VI1PR01MB1823.eurprd01.prod.exchangelabs.com ([10.166.40.21]) by VI1PR01MB1823.eurprd01.prod.exchangelabs.com ([10.166.40.21]) with mapi id 15.01.0466.023; Wed, 20 Apr 2016 19:34:04 +0000 From: "Turner, Randy" To: "core@ietf.org" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRmxxotEPIej5L5ky0Cy8sKtSI55+TDdcAgAAUQ4CAAB7dgA== Date: Wed, 20 Apr 2016 19:34:03 +0000 Message-ID: References: <570A4583.2030100@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=landisgyr.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:cb:c000:8248:4061:d945:dbd2:c314] x-ms-office365-filtering-correlation-id: 84e5806b-436f-4a5c-cf76-08d36952bb8b x-microsoft-exchange-diagnostics: 1; VI1PR01MB1823; 5:fQGRiuEzoAgoxiucRO5zBHaS65ZdCFyE43ZlXQESxXnmN/6MyCQ9rjsrXaRlPwaUHHRFaWtcxqrkvvl4vQRuhzxt5bqZbf6jKw1zyErJroAH9Ae+zWptnJUUc14S3MilzulXqmTAv10YC8/P0DLjofWRodev97YezIc7sVU6daURdKNkcV5BHgMOg0G9BsJX; 24:SlZCFOKBJoIvvP1uX/15p2rLNnl7NfmFlNoQNsUMe1YJE4jUfDrnXdxafOvvQx49BrJYdy2eaMM3b4tuck0fHQilfLS5vBWMFn0gQ0XkEUE=; 7:BgLvKdZXb9YPfFoxZD+okjNu0OX6dgfE2rbYWKgegscbBvkLbio+J1r4dQ9iWri5b9BEqjRVzwhTKzUNFQdK3/pDdbe1q72qJC6cx7VeBlAQCuIIUe8eeL4ev1d5JiSfo1LxpUfNv+E60VoFUdq+jFM3RcuEqVKQtE3SGU9sBi40P+7qHvBxVfwtOkeLbljSGu0Gw641JSVudeSalwltrhwFdbac8kTuU9uCYmL/hUs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR01MB1823; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR01MB1823; BCL:0; PCL:0; RULEID:; SRVR:VI1PR01MB1823; x-forefront-prvs: 0918748D70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(77096005)(82746002)(36756003)(92566002)(110136002)(189998001)(5002640100001)(1220700001)(107886002)(33656002)(6116002)(102836003)(586003)(1096002)(83716003)(1730700002)(87936001)(10400500002)(54356999)(76176999)(5004730100002)(5008740100001)(2906002)(558084003)(5640700001)(3660700001)(122556002)(2501003)(81166005)(86362001)(2351001)(93886004)(3280700002)(2950100001)(229383001)(106116001)(450100001)(2900100001)(50986999)(230783001)(11100500001)(3826002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR01MB1823; H:VI1PR01MB1823.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 19:34:03.9733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB1823 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:34:23 -0000 KzEgYXMgd2VsbOKApnRoZSBkb2N1bWVudCBzZWVtcyB0byBzYXRpc2Z5IHRoZSBwcm9ibGVtIHN0 YXRlbWVudCBhbmQgaXMgbm90IGRlcGVuZGVudCB1cG9uIG9wZXJhdGlvbmFsIHNlbWFudGljcyBh bmQgYXMgc3RhdGVkIGVhcmxpZXIgaGFzIG11bHRpcGxlIGFwcGxpY2FiaWxpdHkgdG8gb3RoZXIg b25nb2luZyAgbWFuYWdlbWVudCBlZmZvcnRzIGluIHRoZSBJRVRGLg0KDQoNClJhbmR5DQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQo= From nobody Wed Apr 20 12:48:58 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1D12E376 for ; Wed, 20 Apr 2016 12:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c85LLKpYWgmv for ; Wed, 20 Apr 2016 12:48:54 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7C812E206 for ; Wed, 20 Apr 2016 12:48:54 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id u8so15305075lbk.0 for ; Wed, 20 Apr 2016 12:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ndTDLaJcf6u9TZW13G5liGiJcsue2MvOS8CL3m/iUAw=; b=k0f6jNyK9sViary8kbfSDW4h6wa83ad9RdKJxikokReRDkCmztJWScLnxHpAEzLry1 LqjRHdvJqLPeikYR9VMV+0OIBgK4MArlXOGXlK2ZRLqKjtw3ajVwFojeXMZ62kP9FZ9r NchUulZ/xi9T1j60iYmQZ2o4Mu3bKWc3mUezVSoERX3PyRsRP65yKd1EnRJ1nQ1Vtk83 GlJ1Ffi/LWEsPPqjOJyt37aIUW8fe3pULz1XYMcKIXWXNq5fjIdGU3VPv+ECwg7Oo5iP 6BdXIkfXyiT/9F8e+Dp1lp5O0p06pP1i5UFPA8/WH9Wq0tMJoq7DvKIELmbIM5XnX1uC rdPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ndTDLaJcf6u9TZW13G5liGiJcsue2MvOS8CL3m/iUAw=; b=NiSMf0Lbzn/rms55jGcoouQqjEuqTBydp0zC9aFRXE8e7InXb79vDNnCtybLnyeheq 0TyRLpCBsEA6s+PnWHatWR8+FX12H4SCOeiSB8zs8cNmCjVWTO4kmxiGq4ANmaqINT8H c8ZaRlR44mzWeSvQ3hwBzKk4ubu0SqZOF/i8DwfjJNUi/yb7W//lev3GPdNTAyZfDlG4 vxFzCU/kTYn1sCuu9jBZkmrLUiXHJhe1AkrFE+EBfgTzOdSb/tZiEQOmzU8SaVDzs/Dv 5R7DMtuyA0TarKKDbj8YIr+CzsNEmNLIJaVbnsNVwKnlJFLJ6vJxHZTE5Oi8IA+Fb93y OBbg== X-Gm-Message-State: AOPr4FX4yUJy7R0ElU45Uiuw1/xzYRUFFqkwL1gYNhUSQs+3i96OuMtPX6ylZGOrt3OqL+gAhC+wy3v8bQStOQ== MIME-Version: 1.0 X-Received: by 10.112.214.235 with SMTP id od11mr2960112lbc.21.1461181732503; Wed, 20 Apr 2016 12:48:52 -0700 (PDT) Received: by 10.112.72.74 with HTTP; Wed, 20 Apr 2016 12:48:52 -0700 (PDT) In-Reply-To: References: <570A4583.2030100@tzi.org> Date: Wed, 20 Apr 2016 15:48:52 -0400 Message-ID: From: James Nguyen To: "Turner, Randy" Content-Type: multipart/alternative; boundary=001a1134b4481e47110530efe2a5 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:48:56 -0000 --001a1134b4481e47110530efe2a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 I support this document. Also, I'd love to see the CoMI as the WG "soon" or Carsten will have to buy me a lot of beers. LOL Thanks, James On Wed, Apr 20, 2016 at 3:34 PM, Turner, Randy wrote: > +1 as well=E2=80=A6the document seems to satisfy the problem statement an= d is not > dependent upon operational semantics and as stated earlier has multiple > applicability to other ongoing management efforts in the IETF. > > > Randy > > > > > > > > > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --=20 James Nguyen Email: james.huy.nguyen@gmail.com --001a1134b4481e47110530efe2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I support this document.=C2= =A0

Also, I'd love to see the CoMI as the WG "soon&q= uot; or Carsten will have to buy me a lot of beers.=C2=A0 LOL

Thanks,

James

On Wed, Apr 20, 2016 at 3:34 PM, Turner, Randy <Randy.Turner@landisgyr.com> wrote:
+1 as well=E2=80=A6the document seems to satisfy the proble= m statement and is not dependent upon operational semantics and as stated e= arlier has multiple applicability to other ongoing=C2=A0 management efforts= in the IETF.


Randy












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



--
James Nguyen
Email: james.huy.nguyen@gmail.com
--001a1134b4481e47110530efe2a5-- From nobody Wed Apr 20 14:07:12 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95412E506 for ; Wed, 20 Apr 2016 14:07:10 -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] 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 Ghxm8rU5DBno for ; Wed, 20 Apr 2016 14:07:08 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3D712E909 for ; Wed, 20 Apr 2016 14:06:59 -0700 (PDT) Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id DDFE341C08E; Wed, 20 Apr 2016 23:06:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 73PAUwYsLYTz; Wed, 20 Apr 2016 23:06:56 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id CCF3941C080; Wed, 20 Apr 2016 23:06:55 +0200 (CEST) Message-ID: <5717EF6D.4030502@tzi.org> Date: Wed, 20 Apr 2016 23:06:53 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: "core@ietf.org WG" , "t2trg@irtf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] Update it or throw it away: IoT Software Update Workshop (IoTSU) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 21:07:11 -0000 While some of us see performing software updates to IoT devices over the Internet as a solved engineering problem, there must be a reason why this capability is not considered a matter of course. This area does need work. We are organizing a workshop on software/firmware updates for IoT devices. More information, with a call for position papers: https://down.dsg.cs.tcd.ie/iotsu/ Grüße, Carsten From nobody Wed Apr 20 14:36:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDA412EDE8; Wed, 20 Apr 2016 14:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NtgbcyM-nDz; Wed, 20 Apr 2016 14:36:42 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5008D12EDE6; Wed, 20 Apr 2016 14:36:42 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o66so68958313ywc.3; Wed, 20 Apr 2016 14:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=A33OmPaQMIprax1YflvykE+63FQcFREBaqHjnSYeRYM=; b=hmvRuRX9mW+9wQi+hv912o/93+IGcpLJ0djBK42MCiD03y898o8GMOGKtC3MLp+A28 9YB11JC+IXxzswf4ioLGO8gESSBsSrlC6kJE1O2EIk4dfNuGrAmQyQfY2i/pCiyLCKHH 5cJhkF+N55LL72O4cY4pn1GuzjJG5+ggTCp3X1ftR1S+yKmXDHSJn63VwEjsMouWaefg 2Ojz/xtxZYISJebavtbmQ+F5c4F01IQzqyR0bSqOk4k2AG0QOGTq+6pTggvI494u6T0t b4QTCWKwPEkyqDPKgLNEIKpg2XUMCu5ZiH47ZRClxLFEwzZs7pNOwD7fP2+KxPdtzeaC /mqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=A33OmPaQMIprax1YflvykE+63FQcFREBaqHjnSYeRYM=; b=j4SnPR0DMxzVHa3TEPYaNQyIiwXQwtBoP/anaqMOzbDKpoVJqIYp1V2sGZi88bunOf QtEVB+nXsklwSmTgfo7DEE2SlQEfodiNJuBsly0PQi89q2enaVLPYb1f5KmTGhX5RGlD MKEwly4iO3clFmOz/gR7pmDBAYKRBYZObDSfQCptgNVLY0VW0bZxXXo7Uu8xlRMSxRps YwemvenR4r5oEvM8zf5oNzHM630K+9D4IiiwGEyfEbl3hsDO3ngKTARvw1uxZWsVl2L7 aSPV7Erj+hdUXLz09biVmtEsF8UlRQ9xsvXTRxH0P2NxAusLWX/5vE/gqxYNMwJW4aOY Xtyg== X-Gm-Message-State: AOPr4FVcdv8YVudgKJ5QxTPD7wdY8XVwtHPUSIJEIb2PbRvETadNVqX2AWa5Ks4ncRC3VXdBys8uzh2yiFkgiA== MIME-Version: 1.0 X-Received: by 10.129.152.8 with SMTP id p8mr6990696ywg.157.1461188201565; Wed, 20 Apr 2016 14:36:41 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Wed, 20 Apr 2016 14:36:41 -0700 (PDT) In-Reply-To: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> References: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 16:36:41 -0500 Message-ID: From: Spencer Dawkins at IETF To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=94eb2c0bc490b45a190530f16394 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , "core@ietf.org" Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-block-19=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 21:36:44 -0000 --94eb2c0bc490b45a190530f16394 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not updating my ballot, but On Wed, Apr 20, 2016 at 6:05 AM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-core-block-19: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-block/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is only a minor point, requesting to spell out implicit assumptions > explicitly. However, I think it's important to address this before > publication. > > It is not clear in the main part of the doc that this extension to does > not change the message transmission method as specified in RFC7252 > (Stop-and-wait retransmission). With my initial ready I assumed that this > extension would allow the sending of back-to-back messages. Only by > looking at the examples, it got clear to me that this is not the case. I was equally confused about something similar - looking at the description (and not the examples), I wasn't sure whether you could send all the blocks of an object, and wait for a response. So, I'd agree with Mirja on her point here. > Further, this document does not say anything about reliability. Do block > message need to be transmitted reliable (as Confirmable)? If not, this > extension could still lead to back-to-back sending and then further > guidance on congestion control would be needed. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with others that reduncy makes the doc harder to read, especially > regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and > MUST in one section and combine the Usage guidance with the examples? > > Further, please also add a reference for ETag in section 2.4. > > > --94eb2c0bc490b45a190530f16394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not updating my ballot, but=C2=A0

On Wed, Apr 20, 2016 at 6:05 AM, M= irja Kuehlewind <ietf@kuehlewind.net> wrote:
Mirja K=C3=BChlewind has entered the following ballot = position for
draft-ietf-core-block-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-c= ore-block/



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

This is only a minor point, requesting to spell out implicit assumptions explicitly. However, I think it's important to address this before
publication.

It is not clear in the main part of the doc that this extension to does
not change the message transmission method as specified in RFC7252
(Stop-and-wait retransmission). With my initial ready I assumed that this extension would allow the sending of back-to-back messages. Only by
looking at the examples, it got clear to me that this is not the case.

I was equally confused about something similar = - looking at the description (and not the examples), I wasn't sure whet= her you could send all the blocks of an object, and wait for a response. So= , I'd agree with Mirja on her point here.
=C2=A0
Further, this document does not say anything about = reliability. Do block
message need to be transmitted reliable (as Confirmable)? If not, this
extension could still lead to back-to-back sending and then further
guidance on congestion control would be needed.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with others that reduncy makes the doc harder to read, especially regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and MUST in one section and combine the Usage guidance with the examples?

Further, please also add a reference for ETag in section 2.4.



--94eb2c0bc490b45a190530f16394-- From nobody Wed Apr 20 22:28:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA212D7D7; Wed, 20 Apr 2016 22:27:56 -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] 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 NKebcKKyFz46; Wed, 20 Apr 2016 22:27:55 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A5112D6BA; Wed, 20 Apr 2016 22:27:54 -0700 (PDT) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 105E1C5A55; Thu, 21 Apr 2016 07:27:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id py42MbDgOh2V; Thu, 21 Apr 2016 07:27:51 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 28CBBC5A50; Thu, 21 Apr 2016 07:27:49 +0200 (CEST) Message-ID: <571864D3.2000906@tzi.org> Date: Thu, 21 Apr 2016 07:27:47 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Spencer Dawkins References: <20160418044805.28780.94432.idtracker@ietfa.amsl.com> In-Reply-To: <20160418044805.28780.94432.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 05:27:57 -0000 Hi Spencer, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please consider whether you need to say more about UDP usage for this > extension than what the base CORE specification says - RFC 7252 has only > one mention of RFC 5405, and that only points to guidance about reducing > ACK_TIMEOUT below one second. I understand that the CoAP story includes > "most of these nodes aren't capable of generating a lot of packets in a > short timeframe", but does this extension make it easier to send multiple > UDP packets back-to-back? The block-wise specification does not say anything about congestion control because it strictly layers on top of RFC 7252 and uses the congestion control specification there (Section 4.7). Back-to-back packets are limited by that section (NSTART as a limit for initiating exchanges, PROBING_RATE as a limit for sending with no response). Block-wise transfers cannot send/solicit more traffic than a client could be sending to the same server without the block-wise mode. > I'm reading this text, > > In most cases, all blocks being transferred for a body (except for > the last one) will be of the same size. > > and then this text > > * The block size implied by SZX MUST match the size of the > payload in bytes, if the M bit is set. (SZX does not govern > the payload size if M is unset). For Block2, if the request > suggested a larger value of SZX, the next request MUST move SZX > down to the size given in the response. (The effect is that, > if the server uses the smaller of (1) its preferred block size > and (2) the block size requested, all blocks for a body use the > same block size.) > > and realizing that I'm confused about why all the blocks for a body might > NOT use the same block size. Maybe this doesn't matter (because an > implementation would need to be prepared for the case when all the blocks > don't use the same block size)? The first request may be using a block size that is larger than what the server prefers. That is one case where the block size changes during a whole transfer. See also Figure 4 for an example where the client prefers a smaller block size than the server sent initially. So, yes, an implementation needs to be prepared for cases where at least the initial block is of a different size than the following (full) blocks. I believe this is evident to the implementers at least from the examples. Grüße, Carsten From nobody Wed Apr 20 22:46:10 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348912E8F3 for ; Wed, 20 Apr 2016 22:46:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 mi61-Kpieaob for ; Wed, 20 Apr 2016 22:46:05 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E3212E8DB for ; Wed, 20 Apr 2016 22:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com; s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RxPgc2i0neIFK90fLCOl50kTq4MgZOPmSm9yp58axrE=; b=oXHDYdbguuT0qO0ysF7hgHousaWoVau9WiJ3IlNq0QJsHh81pfFCaCqavBet11pPnivXi333NK1YR/YINPj9NOdd0+HM6u2coDS/lCk2GnKSrI7Y19XGzJci16BJ/Rs+WNOc6r33WOvsfnw3GhhuRe6qaVwJTjF1a/DKnD4MPUo= Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1840.eurprd06.prod.outlook.com (10.165.237.158) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 05:45:46 +0000 Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 05:45:46 +0000 From: Somaraju Abhinav To: "paduffy@cisco.com" , "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRkyOt4F+Ix0rEaEedjfMR6kWbt5+TEn0AgAAED2OAAAoGAIAA0RKU Date: Thu, 21 Apr 2016 05:45:46 +0000 Message-ID: References: <570A4583.2030100@tzi.org> , <5717B11E.10806@cisco.com> In-Reply-To: <5717B11E.10806@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=tridonic.com; x-originating-ip: [178.165.131.110] x-ms-office365-filtering-correlation-id: 595ddf68-35ae-419e-2176-08d369a82f93 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1840; 5:RFR7X5WGHzftTKa76XhjEzhhLIA/CSuwAJHKK2MzvhgUVhTjK16mfPMfFiSIj84UZ2AP81pYmjzThykQiQXH0bOtGDIx8hzzkFfYs83k5Nrj2tDnFsY7H7liqsEzNeER0hLk4dFZ7k3I+mmUrwtOorYoZuyiLvtqvQGZGHnu/1wECDGv2t7vkyDR78DY6bvO; 24:k+pt3Yr1VOh25lk/G7TEzq0ZuMZSG6J1f2ghtxgRMe1JnY0tnyTn8h9qe50b1IBM8LrUoYy/qrQjMJpbpMhqky0ckFW9LZ/3Doh4YTcYysA=; 7:xS81ojPdt6oS1x6RRW2W3S7EIa/0D7yd7BwMzyNGXJGdmsridpl+U7C60e3REAfhnx1nUZ0XJ/GT+9hm+78c4l5gLXxfsYpVJzgnuhPwpM26D4JFDEtmDzaou2UCCLhy6Vn/z3fruYQ99j39fpdv+vP/84Ag8hFlt5RTiKkD/iS7u2+Lm8faLb4icJ92CZWWa5H8wvF5YzrzHjCTbNpdvYAmynbKdsyLgvzPveD37CE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1840; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR06MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1840; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(189998001)(5001770100001)(1096002)(10400500002)(3900700001)(9686002)(3660700001)(3280700002)(107886002)(1220700001)(33656002)(5008740100001)(92566002)(102836003)(81166005)(3846002)(6116002)(16236675004)(2906002)(19625215002)(76576001)(66066001)(5004730100002)(50986999)(76176999)(54356999)(230783001)(2900100001)(15975445007)(77096005)(2950100001)(19617315012)(5890100001)(2501003)(19580405001)(19580395003)(87936001)(74316001)(86362001)(586003)(5003600100002)(93886004)(5002640100001)(19627405001)(122556002)(11100500001)(229383001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1840; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR06MB18395917B148B4900842F399FC6E0VI1PR06MB1839eurp_" MIME-Version: 1.0 X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 05:45:46.0778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1840 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 05:46:08 -0000 --_000_VI1PR06MB18395917B148B4900842F399FC6E0VI1PR06MB1839eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KaXQgaXMgZ29vZCB0byBoZWFyIGZyb20geW91IC0gSSBhbSBmYW1pbGlhciB3 aXRoIHRoZSBnb29kIHdvcmsgYmVpbmcgZG9uZSB3aXRoaW4gdGhlIGRpZ2l0YWwgY2VpbGluZyBn cm91cCBhdCBDaXNjby4NCg0KDQpXaGVuIHdlIHN0YXJ0ZWQgbG9va2luZyBmb3IgYSBtb2RlbGxp bmcgdG9vbCBhYm91dCA2IHRvIDkgbW9udGhzIGJhY2ssIFJBTUwrSlNPTiBzY2hlbWEgd2FzIG9u ZSBvZiB0aGUgb3B0aW9ucyB3ZSBsb29rZWQgYXQgYW5kIGl0IHdhcyBhbiBvcHRpb24gSSB3YXMg bm90IHRvbyB1bmhhcHB5IHRvIHVzZS4gSG93ZXZlciwgWUFORyB0dXJuZWQgb3V0IHRvIGJlIGEg YmV0dGVyIHNvbHV0aW9uIGZvciBzZXZlcmFsIHJlYXNvbnMgYW5kIEkgbGlzdCB0aGUgdGhyZWUg bWFpbiBvbmVzIGluIGRlY3JlYXNpbmcgb3JkZXIgb2YgaW1wb3J0YW5jZSBmcm9tIG15IHBvaW50 IG9mIHZpZXcuDQoNCg0KMSkgU3RhbmRhcmRpemF0aW9uOiBJIHBlcnNvbmFsbHkgZG8gbm90IGhh dmUgYSBwcm9ibGVtIHdpdGggdXNpbmcgYSBzdGFuZGFyZCB0aGF0IGlzIHN1Yi1vcHRpbWFsIGZv ciBteSBwcm9ibGVtIGFzIGxvbmcgYXMgdGhlcmUgaXMgb25lIHNvbHV0aW9uIHRoYXQgaXMgYmVp bmcgYWRvcHRlZCBpbiB0aGUgZmllbGQuIEZvciBjb25zdHJhaW5lZCBkZXZpY2UgbWFuYWdlbWVu dCwgdGhlcmUgd2VyZSBubyByZWFsIHByb2R1Y3RzIGluIHRoZSBmaWVsZCBzbyB3ZSBsb29rZWQg YXQgdGhlIHR3byBvcHRpb25zIG9mIFJBTUwrSlNPTiBzY2hlbWEgYW5kIFlBTkcuIFlBTkcgc2Vl bXMgdG8gYmUgZ2FpbmluZyBhIGxvdCBvZiBtb21lbnR1bSB3aXRoIHRoZSBhZG9wdGlvbiBvZiBO RVRDT05GL1JFU1RDT05GIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQuIEZvciBpbnN0YW5jZSBpdCBs b29rcyBsaWtlIDZUaXNoLCBMUFdBTiwgQW5pbWEgZXRjLiBhcmUgcGFubmluZyBvbiB1c2luZyBp dCBhbHJlYWR5LiBXaXRoIHJlZ2FyZHMgdG8gT0NGLCBJIGN1cnJlbnRseSBzZWUgbm8gcHJvZHVj dHMgaW4gdGhlIGZpZWxkIGFuZCBJb1Rpdml0eSBpcyB3YXkgdG9vIGJsb2F0ZWQgZm9yIG1lIHRv IGJ1aWxkIHByb2R1Y3RzIG9uIHNtYWxsIENvcnRleC1NIHR5cGUgY29udHJvbGxlcnMgYXQgdGhl IG1vbWVudC4gU28sIEkgZG8gbm90IHlldCBzZWUgZW5vdWdoIHVzYWdlIG9mIFJBTUwrSlNPTiBp biB0aGUgY29uc3RyYWluZWQgZGV2aWNlIHdvcmxkIGFuZCBzZWUgWUFORyBiZWNvbWluZyBhIHZl cnkgd2VsbCB1c2VkIHRvb2wgaW4gdGhlIG5ldHdvcmsgbWFuYWdlbWVudCBjb21tdW5pdHkuDQoN Cg0KMikgVGVjaG5pY2FsOiBGcm9tIGEgdGVjaG5pY2FsIHBvaW50IG9mIHZpZXcsIFlBTkcgcHJv dmlkZXMgbWUgdGhlIHJpZ2h0IGtpbmQgb2YgYWRkaXRpb25hbCBvcHRpb25zIHRvIHNwZWNpZnkg YW4gaW50ZXJvcGVyYWJsZSBsaWdodGluZyByZXNvdXJjZSBtb2RlbC4gSU1PLCB0aGUgbWFpbiB0 ZWNobmljYWwgZGlmZmVyZW5jZSBiZXR3ZWVuIFlBTkcgYW5kIFJBTUwrc2NoZW1hIGlzIHRoYXQg dGhlIGxhdGVyIGZpeGVzIHRoZSBzeW50YXggb2YgYW55IGNsaWVudC1zZXJ2ZXIgaW50ZXJhY3Rp b24gYnV0IHRoZSBmb3JtZXIgY2FuIGFsc28gYmUgdXNlZCB0byBtb2RlbCBzZW1hbnRpY3MuIEZv ciBleGFtcGxlLCBJIHdvdWxkIGxpa2UgbXkgbHVtaW5hcmUgcmVzb3VyY2UgbW9kZWwgdG8gcHJv dmlkZSBhbiBBUEkgZm9yIGFjY2Vzc2luZyBsaWdodCBpbnRlbnNpdHkgYnV0IGFsc28gYmUgYWJs ZSB0byB0ZWxsIHdoaWNoIHN0YXRlIHRoZSBsdW1pbmFyaWVzIGdvIHRvIGlmIHRoZXJlIHdhcyBh IHBvd2VyIGN5Y2xlIGFuZC9vciBpZiBuZXR3b3JrIGNvbm5lY3Rpdml0eSBpcyBsb3N0IHRvIHRo ZSBzZXJ2ZXIuIEkgd2FudCB0aGVzZSB0byBiZSBzcGVjaWZpZWQgbm90IGJ5IGEgY2xpZW50IHdy aXRpbmcgdG8gc3BlY2lmaWMgcmVzb3VyY2VzIGluIHRoZSBsdW1pbmFpcmUgb2JqZWN0IGJ1dCBh cyBhIHBhcnQgb2YgYSBzdGFuZGFyZCBzbyB0aGF0IGFsbCBsdW1pbmFpcnMgZnJvbSBkaWZmZXJl bnQgbWFudWZhY3R1cmVycyBiZWhhdmUgaW4gdGhlIHNhbWUgc3RhbmRhcmQgbWFubmVyLiBBIHNl Y29uZCBleGFtcGxlIGlzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIGNhdGVnb3JpemUgbXkgZGF0YSBp bnRvIGRpZmZlcmVudCBibG9ja3MgYmFzZWQgb24gdXNhZ2UgYnkgY29tbWlzc2lvbmluZy9tYWlu dGVuYW5jZSBlbmdpbmVlcnMuIFRoZXJlIGFyZSBzZXZlcmFsIGV4YW1wbGUgd2hlcmUgcmVxdWly aW5nIGludGVyb3BlcmFibGUgYmVoYXZpb3VyIG9mIHNlbnNvcnMvYWN0dWF0b3JzIGluIHRoZSBm aWVsZCByZXF1aXJlcyBtZSB0byBub3Qgb25seSBzdGFuZGFyZGl6ZSB0aGUgc3ludGF4IGJ1dCBh bHNvIHRoZSBzZW1hbnRpY3Mgb2YgbXkgaW5mb3JtYXRpb24gbW9kZWwuIEFsc28sIHNwZWNpZnlp bmcgWUFORyArIGNvbnZlcnNpb24gcnVsZXMgdG8gSlNPTiwgWE1MLCBDQk9SIGV0Yy4gYWxsb3dz IG1lIHRvIGNhcnJ5IGFueSBtZWRpYS10eXBlIHVzaW5nIGEgc2luZ2xlIGluZm9ybWF0aW9uIG1v ZGVsLiBJIGRvIG5vdCB3YW50IHRvIHVzZSBKU09OIGluIHRoZSBjb25zdHJhaW5lZCBuZXR3b3Jr cyBhbmQgd2lsbCBiZSB1c2luZyBDQk9SLiBUaG91Z2gsIGl0IGlzIHBvc3NpYmxlIGZvciBtZSB0 byBzdGFydCB3aXRoIEpTT04gc2NoZW1hIGFuZCBjYXJyeSBDQk9SIHBheWxvYWQsIHRoaXMgZG9l cyBub3QgbWFrZSB1c2Ugb2YgYWxsIHRoZSBvcHRpbWl6YXRpb25zIHRoYXQgYXJlIHBvc3NpYmxl IGluIEpTT04uIEFsc28sIFlBTkcgaGFzIHNvbWUgYWRkaXRpb25hbCBmZWF0dXJlcywgZS5nLiBu b3RpZmljYXRpb25zIHRoYXQgYXJlIHZlcnkgaW1wb3J0YW50IGluIGV2ZW50IGRyaXZlbiBsb2Nh bCBjb250cm9sIHRoYXQgaGF2ZSBubyBjb3VudGVycGFydCB0aGF0IEkga25vdyBvZiBpbiBSQU1M Lg0KDQoNCjMpIFRvb2xpbmc6IEluIHRoaXMgcmVzcGVjdCBSQU1MK0pTT04gaXMgYmV0dGVyLCBi dXQgbm90IG11Y2ggYmV0dGVyLiBUaGUgbWFpbiBpc3N1ZSBpcyB0aGF0IHRoZXJlIGFyZSB0b29s cyBhdmFpbGFibGUgdG8gZ28gZnJvbSBSQU1MK0pTT04gdG8gd2ViIHNlcnZlciBhcHBsaWNhdGlv bnMuIEhvd2V2ZXIsIHRvIHRyYW5zbGF0ZSB0aGUgSW50ZXJmYWNlK3NjaGVtYSB0byBjL2MrKyBv biBzbWFsbCBlbWJlZGRlZCBkZXZpY2UsIHRoZXJlIGRvbid0IHNlZW0gdG8gYmUgdG9vIG1hbnkg b3B0aW9ucyBBVE0uDQoNCg0KVG8gc3VtbWFyaXplLCBJIHRoaW5rIGl0IGlzIGVzc2VudGlhbCB0 aGF0IHRoZSBpbmR1c3RyeSBhbGlnbnMgYXJvdW5kIG9uZSBtb2RlbGxpbmcgbGFuZ3VhZ2UgYW5k IEkgd291bGQgbm90IGhhdmUgdG9vIG11Y2ggb2YgYSBwcm9ibGVtIGlmIHRoaXMgd2FzIFJBTUwr SlNPTi4gSG93ZXZlciwgSSBkbyBub3Qgc2VlIHRoYXQgaGFwcGVuaW5nIHJpZ2h0IG5vdyBhbmQg WUFORytDQk9SIHNlZW1zIHRvIGJlIG1vcmUgc3VpdGVkIHRvIHRoZSBjb25zdHJhaW5lZCBuZXR3 b3JrL2NvbnN0cmFpbmVkIGRldmljZXMgYXBwbGljYXRpb24gd2l0aCBtb3JlIG1vbWVudHVtIGJl Y2F1c2UgaXQgaXMgYmVpbmcgdXNlZCBpbiB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFwcGxpY2F0 aW9ucy4NCg0KDQpSZWdhcmRzLA0KDQpBYmhpbmF2DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBQYXVsIER1ZmZ5IDxwYWR1ZmZ5QGNpc2NvLmNvbT4NClNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgNjo0MSBQTQ0KVG86IFNvbWFyYWp1IEFiaGluYXYNClN1 YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29y ZS15YW5nLWNib3ItbWFwcGluZy0wMA0KDQpHcmVldGluZ3MgU29tYXJhanUNCg0KQlRXIEkgYW0g YSBtZW1iZXIgb2YgdGhlIENpc2NvIERpZ2l0YWwgQ2VpbGluZyB0ZWFtIChhbW9uZ3N0IG90aGVy IG1hdHRlcnMpLg0KDQpXaGF0IGFyZSB5b3VyIGlzc3VlcyB3aXRoIEpTT04gU2NoZW1hIHZlcnN1 cyBZQU5HPw0KDQpPQ0YgaGFzIGFkb3B0ZWQgUkFNTCBmb3IgUkVTVGZ1bCBpbnRlcmZhY2UgZGVm aW5pdGlvbnMuICBDaXNjbyBpcyBzdXBwb3J0aXZlIG9mIFJBTUwgYW5kIFJBTUwgKyBKU09OIFNj aGVtYS4gIFdlIHRoaW5rIHRoaXMgaXMgZ29vZCBhcHByb2FjaC4gIFJlYXNvbnM6IFlBTkcgdG9v bHMgZWNvc3lzdGVtIC8gc3VwcG9ydCBmb3IgWUFORyBpcyBnZW5lcmFsbHkgcG9vciwgYW5kIEpT T04gZ2VuZXJhbGx5IGhhcyBodWdlIHRyYWN0aW9uIGFuZCBncmVhdCB0b29saW5nIHN1cHBvcnQu DQoNCllBTkcgdG8gQ0JPUiBzZWVtcyBhIGxhcmdlIGltcGVkYW5jZSBtaXNtYXRjaC4NCg0KPw0K DQpDaGVlcnMNCg0KDQpPbiA0LzIwLzIwMTYgMTI6MDggUE0sIFNvbWFyYWp1IEFiaGluYXYgd3Jv dGU6DQoNCkhpLA0KDQpJIChhcyBhbiBhdXRob3IpIGFtIGluIGZhdm91ciBvZiBhZG9wdGlvbi4N Cg0KDQpXZSBwbGFuIHRvIHVzZSBZYW5nIHRvIG1vZGVsIHJlc291cmNlcyBpbiBsaWdodGluZyBh bmQgYnVpbGRpbmcgYXV0b21hdGlvbiBhcHBsaWNhdGlvbnMgYW5kIHdpbGwgdXNlIHRoZSBZYW5n LUNib3IgbWFwcGluZyBkcmFmdCB0byBzcGVjaWZ5IGhvdyB0aGUgcGF5bG9hZCB3aWxsIGJlIGZv cm1hdHRlZCBpbiBDQk9SIGluc3RlYWQgb2YgdXNpbmcgSlNPTi9YTUwgc2NoZW1hIGRlZmluaXRp b25zLg0KDQoNCkFiaGluYXYNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RnJvbTogY29yZSA8Y29yZS1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+PG1h aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIwLCAyMDE2 IDU6NTAgUE0NClRvOiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBjb3JlQGlldGYub3JnPG1haWx0bzpj b3JlQGlldGYub3JnPiBXRw0KU3ViamVjdDogUmU6IFtjb3JlXSDwn5SUIFdHIGFkb3B0aW9uIG9m IGRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1tYXBwaW5nLTAwDQoNCkhpLA0KDQpJIGFt IGluIGZhdm9yIG9mIGFkb3B0aW9uLg0KV2UgcGxhbiB0byBpbXBsZW1lbnQgdGhpcyBkcmFmdCBm b3IgdXNlIHdpdGggQ29NSQ0KYW5kIHBvc3NpYmx5IFJFU1RDT05GLg0KDQoNCkFuZHkNCg0KDQpP biBTdW4sIEFwciAxMCwgMjAxNiBhdCA1OjIyIEFNLCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHpp Lm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gd3JvdGU6DQpJbiBCdWVub3MgQWlyZXMsIHdlIGRp c2N1c3NlZCB0aGUgYWRvcHRpb24gb2YNCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1t YXBwaW5nLTAwIGJ1dCBub3QgZW5vdWdoIHBlb3BsZSBoYWQgcmVhZA0KdGhlIGRvY3VtZW50IHRv IGdvIGZvciBhbiBpbi1yb29tIGNvbnNlbnN1cyBjYWxsLg0KDQpUaGlzIGlzIGEgdHdvLXdlZWsg Y2FsbCBmb3IgYWRvcHRpb24gb2YNCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1tYXBw aW5nLTAwIGFzIGEgV0cgZG9jdW1lbnQgb2YgQ29SRS4NClNwZWNpZmljYWxseSwgaWYgeW91ICgx KSBzdXBwb3J0IG9yICgyKSBoYXZlIGFuIG9iamVjdGlvbiB0byB0aGlzDQpkZWNpc2lvbiwgcGxl YXNlIHNwZWFrIHVwIG9uIHRoZSBtYWlsaW5nIGxpc3QgYnkgMjAxNi0wNC0yNC4NCg0KTm90ZSB0 aGF0IHRoaXMgd29yayBpcyBleHBsaWNpdGx5IGNvdmVyZWQgYnkgb3VyIGNoYXJ0ZXIsIHNvIGRp c2N1c3Npb25zDQpvZiB3aGljaCBXRyBzaG91bGQgd29yayBvbiB0aGlzIGFyZSBvZmYtdG9waWMu DQoNCkFzIGFsd2F5cywgYWRvcHRpb24gb2YgYSBkb2N1bWVudCBhcyBhIFdHIGRvY3VtZW50IGlz IG5vdCBhIHZvdGUgb24NCndoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFzdC1jYWxs IHN0YXRlOyB0aGUgaW50ZW50aW9uIGlzIHRvDQp3b3JrIG9uIHRoZSBXRyBkb2N1bWVudCBhZnRl ciBhZG9wdGlvbiBmb3IgYSB3aGlsZSB0byBnZXQgaXQgcmVhZHkgZm9yDQpsYXN0IGNhbGwuICBJ ZiB5b3Ugd2FudCB0byBjb21iaW5lIHlvdXIgc3VwcG9ydC9vYmplY3Rpb24gd2l0aCB0ZWNobmlj YWwNCmNvbW1lbnRzLCB0aGlzIGlzIGNlcnRhaW5seSB3ZWxjb21lIHNvIHdlIGNhbiBhY2NlbGVy YXRlIHRoYXQgcHJvY2Vzcy4NCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVA aWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBU aGV5IG1heSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueSB3 YXkgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBl LW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4gUGxl YXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBzZW5kZXIncyBjb21wYW55 IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVz cG9uc2liaWxpdHkgdG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhpcyBlLW1haWwgYW5kIGFu eSBhdHRhY2htZW50cy4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNj bG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIg dGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRo ZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25z aWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0eSB0byBzY2Fu IG9yIG90aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0K --_000_VI1PR06MB18395917B148B4900842F399FC6E0VI1PR06MB1839eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3Vu ZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMt c2VyaWY7Ij4NCjxwPkhpIFBhdWwsPC9wPg0KPHA+aXQgaXMgZ29vZCB0byBoZWFyIGZyb20geW91 IC0gSSBhbSBmYW1pbGlhciB3aXRoIHRoZSZuYnNwO2dvb2Qgd29yayBiZWluZyBkb25lIHdpdGhp biB0aGUgZGlnaXRhbCBjZWlsaW5nIGdyb3VwJm5ic3A7YXQgQ2lzY28uPC9wPg0KPHA+PGJyPg0K PC9wPg0KPHA+V2hlbiB3ZSBzdGFydGVkIGxvb2tpbmcgZm9yIGEgbW9kZWxsaW5nIHRvb2wgYWJv dXQgNiB0byA5IG1vbnRocyBiYWNrLCBSQU1MJiM0MztKU09OIHNjaGVtYSB3YXMgb25lIG9mIHRo ZSBvcHRpb25zIHdlIGxvb2tlZCBhdCBhbmQgaXQgd2FzIGFuIG9wdGlvbiBJIHdhcyBub3QgdG9v IHVuaGFwcHkgdG8gdXNlLiBIb3dldmVyLCBZQU5HIHR1cm5lZCBvdXQgdG8gYmUgYSBiZXR0ZXIg c29sdXRpb24gZm9yIHNldmVyYWwgcmVhc29ucyBhbmQgSSBsaXN0DQogdGhlJm5ic3A7dGhyZWUg bWFpbiBvbmVzJm5ic3A7aW4gZGVjcmVhc2luZyBvcmRlciBvZiBpbXBvcnRhbmNlIGZyb20gbXkg cG9pbnQgb2Ygdmlldy48L3A+DQo8cD48YnI+DQo8L3A+DQo8cD4xKSBTdGFuZGFyZGl6YXRpb246 IEkgcGVyc29uYWxseSBkbyBub3QgaGF2ZSBhIHByb2JsZW0gd2l0aCB1c2luZyBhIHN0YW5kYXJk IHRoYXQgaXMgc3ViLW9wdGltYWwgZm9yIG15IHByb2JsZW0gYXMgbG9uZyBhcyB0aGVyZSBpcyBv bmUgc29sdXRpb24gdGhhdCBpcyBiZWluZyBhZG9wdGVkIGluIHRoZSBmaWVsZC4gRm9yIGNvbnN0 cmFpbmVkIGRldmljZSBtYW5hZ2VtZW50LCB0aGVyZSB3ZXJlIG5vIHJlYWwgcHJvZHVjdHMgaW4g dGhlIGZpZWxkDQogc28gd2UgbG9va2VkIGF0IHRoZSB0d28gb3B0aW9ucyBvZiBSQU1MJiM0MztK U09OIHNjaGVtYSBhbmQgWUFORy4gWUFORyBzZWVtcyB0byBiZSBnYWluaW5nIGEgbG90IG9mIG1v bWVudHVtIHdpdGggdGhlIGFkb3B0aW9uIG9mIE5FVENPTkYvUkVTVENPTkYgZm9yIG5ldHdvcmsg bWFuYWdlbWVudC4gRm9yIGluc3RhbmNlIGl0Jm5ic3A7bG9va3MgbGlrZSA2VGlzaCwgTFBXQU4s IEFuaW1hIGV0Yy4gYXJlIHBhbm5pbmcgb24gdXNpbmcgaXQgYWxyZWFkeS4gV2l0aA0KIHJlZ2Fy ZHMgdG8gT0NGLCBJIGN1cnJlbnRseSBzZWUgbm8gcHJvZHVjdHMgaW4gdGhlIGZpZWxkIGFuZCBJ b1Rpdml0eSBpcyB3YXkgdG9vIGJsb2F0ZWQgZm9yIG1lIHRvIGJ1aWxkIHByb2R1Y3RzIG9uIHNt YWxsIENvcnRleC1NIHR5cGUgY29udHJvbGxlcnMgYXQgdGhlIG1vbWVudC4gU28sIEkgZG8gbm90 IHlldCBzZWUgZW5vdWdoIHVzYWdlIG9mIFJBTUwmIzQzO0pTT04gaW4gdGhlIGNvbnN0cmFpbmVk IGRldmljZSB3b3JsZCBhbmQgc2VlIFlBTkcNCiBiZWNvbWluZyBhIHZlcnkgd2VsbCB1c2VkIHRv b2wgaW4gdGhlIG5ldHdvcmsgbWFuYWdlbWVudCBjb21tdW5pdHkuPC9wPg0KPHA+PGJyPg0KPC9w Pg0KPHA+MikgVGVjaG5pY2FsOiBGcm9tIGEgdGVjaG5pY2FsIHBvaW50IG9mIHZpZXcsIFlBTkcg cHJvdmlkZXMgbWUgdGhlIHJpZ2h0IGtpbmQgb2YgYWRkaXRpb25hbCBvcHRpb25zIHRvIHNwZWNp ZnkgYW4gaW50ZXJvcGVyYWJsZSBsaWdodGluZyByZXNvdXJjZSBtb2RlbC4gSU1PLCB0aGUgbWFp biB0ZWNobmljYWwmbmJzcDtkaWZmZXJlbmNlIGJldHdlZW4gWUFORyBhbmQgUkFNTCYjNDM7c2No ZW1hIGlzIHRoYXQgdGhlIGxhdGVyIGZpeGVzIHRoZSBzeW50YXggb2YNCiBhbnkmbmJzcDtjbGll bnQtc2VydmVyIGludGVyYWN0aW9uIGJ1dCB0aGUgZm9ybWVyJm5ic3A7Y2FuIGFsc28gYmUgdXNl ZCB0byBtb2RlbCZuYnNwO3NlbWFudGljcy4gRm9yIGV4YW1wbGUsIEkgd291bGQgbGlrZSBteSBs dW1pbmFyZSByZXNvdXJjZSBtb2RlbCB0byBwcm92aWRlIGFuIEFQSSBmb3IgYWNjZXNzaW5nIGxp Z2h0IGludGVuc2l0eSBidXQgYWxzbyBiZSBhYmxlIHRvIHRlbGwgd2hpY2ggc3RhdGUgdGhlIGx1 bWluYXJpZXMgZ28gdG8gaWYgdGhlcmUgd2FzIGENCiBwb3dlciBjeWNsZSBhbmQvb3IgaWYgbmV0 d29yayZuYnNwO2Nvbm5lY3Rpdml0eSBpcyBsb3N0IHRvIHRoZSBzZXJ2ZXIuIEkgd2FudCB0aGVz ZSB0byBiZSBzcGVjaWZpZWQgbm90IGJ5IGEgY2xpZW50IHdyaXRpbmcgdG8gc3BlY2lmaWMgcmVz b3VyY2VzIGluIHRoZSBsdW1pbmFpcmUgb2JqZWN0IGJ1dCBhcyBhIHBhcnQgb2YgYSBzdGFuZGFy ZCBzbyB0aGF0IGFsbCBsdW1pbmFpcnMgZnJvbSBkaWZmZXJlbnQgbWFudWZhY3R1cmVycyBiZWhh dmUgaW4gdGhlDQogc2FtZSBzdGFuZGFyZCBtYW5uZXIuJm5ic3A7QSBzZWNvbmQgZXhhbXBsZSBp cyB0aGF0IEkgd291bGQgbGlrZSB0byBjYXRlZ29yaXplIG15IGRhdGEgaW50byBkaWZmZXJlbnQg YmxvY2tzIGJhc2VkIG9uIHVzYWdlIGJ5IGNvbW1pc3Npb25pbmcvbWFpbnRlbmFuY2UgZW5naW5l ZXJzLiZuYnNwO1RoZXJlIGFyZSBzZXZlcmFsIGV4YW1wbGUgd2hlcmUgcmVxdWlyaW5nIGludGVy b3BlcmFibGUgYmVoYXZpb3VyIG9mIHNlbnNvcnMvYWN0dWF0b3JzIGluIHRoZSBmaWVsZCZuYnNw O3JlcXVpcmVzDQogbWUgdG8gbm90IG9ubHkgc3RhbmRhcmRpemUgdGhlIHN5bnRheCBidXQgYWxz byB0aGUgc2VtYW50aWNzIG9mIG15IGluZm9ybWF0aW9uIG1vZGVsLiBBbHNvLCBzcGVjaWZ5aW5n IFlBTkcgJiM0MzsgY29udmVyc2lvbiBydWxlcyB0byBKU09OLCBYTUwsIENCT1IgZXRjLiBhbGxv d3MgbWUgdG8gY2FycnkgYW55IG1lZGlhLXR5cGUgdXNpbmcgYSBzaW5nbGUgaW5mb3JtYXRpb24g bW9kZWwuIEkgZG8gbm90IHdhbnQgdG8gdXNlIEpTT04gaW4gdGhlIGNvbnN0cmFpbmVkDQogbmV0 d29ya3MgYW5kIHdpbGwgYmUgdXNpbmcgQ0JPUi4mbmJzcDtUaG91Z2gsIGl0IGlzIHBvc3NpYmxl IGZvciBtZSB0byBzdGFydCB3aXRoIEpTT04gc2NoZW1hIGFuZCBjYXJyeSBDQk9SIHBheWxvYWQs Jm5ic3A7dGhpcyBkb2VzIG5vdCBtYWtlIHVzZSBvZiBhbGwgdGhlIG9wdGltaXphdGlvbnMgdGhh dCBhcmUgcG9zc2libGUgaW4gSlNPTi4gQWxzbywgWUFORyBoYXMgc29tZSBhZGRpdGlvbmFsIGZl YXR1cmVzLCBlLmcuIG5vdGlmaWNhdGlvbnMgdGhhdCBhcmUNCiB2ZXJ5IGltcG9ydGFudCBpbiBl dmVudCBkcml2ZW4gbG9jYWwgY29udHJvbCZuYnNwO3RoYXQgaGF2ZSBubyBjb3VudGVycGFydCB0 aGF0IEkga25vdyBvZiBpbiBSQU1MLjwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPjMpIFRvb2xpbmc6 IEluIHRoaXMgcmVzcGVjdCBSQU1MJiM0MztKU09OIGlzIGJldHRlciwgYnV0IG5vdCBtdWNoIGJl dHRlci4gVGhlIG1haW4gaXNzdWUgaXMgdGhhdCB0aGVyZSBhcmUgdG9vbHMgYXZhaWxhYmxlIHRv IGdvIGZyb20gUkFNTCYjNDM7SlNPTiB0byB3ZWIgc2VydmVyIGFwcGxpY2F0aW9ucy4gSG93ZXZl ciwgdG8gdHJhbnNsYXRlIHRoZSBJbnRlcmZhY2UmIzQzO3NjaGVtYSB0byBjL2MmIzQzOyYjNDM7 IG9uIHNtYWxsIGVtYmVkZGVkIGRldmljZSwgdGhlcmUgZG9uJ3QNCiBzZWVtIHRvIGJlIHRvbyBt YW55IG9wdGlvbnMgQVRNLiZuYnNwOzwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPlRvIHN1bW1hcml6 ZSwgSSB0aGluayBpdCBpcyBlc3NlbnRpYWwgdGhhdCB0aGUgaW5kdXN0cnkgYWxpZ25zIGFyb3Vu ZCBvbmUgbW9kZWxsaW5nIGxhbmd1YWdlIGFuZCZuYnNwO0kgd291bGQgbm90IGhhdmUmbmJzcDt0 b28gbXVjaCBvZiBhJm5ic3A7cHJvYmxlbSBpZiB0aGlzIHdhcyBSQU1MJiM0MztKU09OLiBIb3dl dmVyLCBJIGRvIG5vdCBzZWUgdGhhdCBoYXBwZW5pbmcgcmlnaHQgbm93IGFuZCBZQU5HJiM0MztD Qk9SIHNlZW1zIHRvIGJlJm5ic3A7bW9yZSBzdWl0ZWQgdG8gdGhlIGNvbnN0cmFpbmVkDQogbmV0 d29yay9jb25zdHJhaW5lZCBkZXZpY2VzIGFwcGxpY2F0aW9uIHdpdGggbW9yZSBtb21lbnR1bSBi ZWNhdXNlJm5ic3A7aXQgaXMmbmJzcDtiZWluZyB1c2VkJm5ic3A7aW4gdGhlIG5ldHdvcmsgbWFu YWdlbWVudCBhcHBsaWNhdGlvbnMuJm5ic3A7Jm5ic3A7PC9wPg0KPHA+PGJyPg0KPC9wPg0KPHA+ UmVnYXJkcyw8L3A+DQo8cD5BYmhpbmF2PC9wPg0KPGJyPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KPGhyIHRhYmluZGV4PSItMSIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJs b2NrOyB3aWR0aDo5OCUiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250 IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iZm9udC1z aXplOjExcHQiPjxiPkZyb206PC9iPiBQYXVsIER1ZmZ5ICZsdDtwYWR1ZmZ5QGNpc2NvLmNvbSZn dDs8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyMCwgMjAxNiA2OjQxIFBNPGJy Pg0KPGI+VG86PC9iPiBTb21hcmFqdSBBYmhpbmF2PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb Y29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3It bWFwcGluZy0wMDwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkdyZWV0aW5ncyBTb21hcmFqdTxicj4NCjxicj4NCkJU VyBJIGFtIGEgbWVtYmVyIG9mIHRoZSBDaXNjbyBEaWdpdGFsIENlaWxpbmcgdGVhbSAoYW1vbmdz dCBvdGhlciBtYXR0ZXJzKS4mbmJzcDsgPGJyPg0KPGJyPg0KV2hhdCBhcmUgeW91ciBpc3N1ZXMg d2l0aCBKU09OIFNjaGVtYSB2ZXJzdXMgWUFORz88YnI+DQo8YnI+DQpPQ0YgaGFzIGFkb3B0ZWQg UkFNTCBmb3IgUkVTVGZ1bCBpbnRlcmZhY2UgZGVmaW5pdGlvbnMuJm5ic3A7IENpc2NvIGlzIHN1 cHBvcnRpdmUgb2YgUkFNTCBhbmQgUkFNTCAmIzQzOyBKU09OIFNjaGVtYS4mbmJzcDsgV2UgdGhp bmsgdGhpcyBpcyBnb29kIGFwcHJvYWNoLiZuYnNwOyBSZWFzb25zOiBZQU5HIHRvb2xzIGVjb3N5 c3RlbSAvIHN1cHBvcnQgZm9yIFlBTkcgaXMgZ2VuZXJhbGx5IHBvb3IsIGFuZCBKU09OIGdlbmVy YWxseSBoYXMgaHVnZSB0cmFjdGlvbiBhbmQgZ3JlYXQNCiB0b29saW5nIHN1cHBvcnQuPGJyPg0K PGJyPg0KWUFORyB0byBDQk9SIHNlZW1zIGEgbGFyZ2UgaW1wZWRhbmNlIG1pc21hdGNoLjxicj4N Cjxicj4NCj88YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQo8YnI+DQo8YnI+DQpPbiA0LzIwLzIwMTYg MTI6MDggUE0sIFNvbWFyYWp1IEFiaGluYXYgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBzdHlsZT0iZm9u dC1zaXplOjEycHQ7IGNvbG9yOiMwMDAwMDA7IGJhY2tncm91bmQtY29sb3I6I0ZGRkZGRjsgZm9u dC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQo8cD5IaSw8L3A+ DQo8cD5JIChhcyBhbiBhdXRob3IpIGFtIGluIGZhdm91ciBvZiBhZG9wdGlvbi4mbmJzcDs8L3A+ DQo8cD48YnI+DQo8L3A+DQo8cD5XZSBwbGFuIHRvIHVzZSBZYW5nIHRvIG1vZGVsIHJlc291cmNl cyBpbiBsaWdodGluZyBhbmQgYnVpbGRpbmcgYXV0b21hdGlvbiBhcHBsaWNhdGlvbnMgYW5kIHdp bGwgdXNlIHRoZSBZYW5nLUNib3IgbWFwcGluZyBkcmFmdCB0byBzcGVjaWZ5IGhvdyB0aGUgcGF5 bG9hZCB3aWxsIGJlIGZvcm1hdHRlZCBpbiBDQk9SIGluc3RlYWQgb2YgdXNpbmcgSlNPTi9YTUwg c2NoZW1hIGRlZmluaXRpb25zLiZuYnNwOzwvcD4NCjxwPjxicj4NCjwvcD4NCjxwPkFiaGluYXY8 L3A+DQo8YnI+DQo8YnI+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApIj4NCjxociB0YWJp bmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4NCjxkaXYg aWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgZmFjZT0i Q2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4g Y29yZQ0KPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZyI+Jmx0O2NvcmUtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJl aGFsZiBvZiBBbmR5IEJpZXJtYW4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhy ZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPiZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7 PC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDIwLCAyMDE2IDU6NTAgUE08 YnI+DQo8Yj5Ubzo8L2I+IENhcnN0ZW4gQm9ybWFubjxicj4NCjxiPkNjOjwvYj4gPGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNv cmVAaWV0Zi5vcmc8L2E+IFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0g8J+UlCBX RyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMDwv Zm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5I aSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYW0gaW4gZmF2b3Igb2YgYWRvcHRpb24uPC9k aXY+DQo8ZGl2PldlIHBsYW4gdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQgZm9yIHVzZSB3aXRoIENv TUk8L2Rpdj4NCjxkaXY+YW5kIHBvc3NpYmx5IFJFU1RDT05GLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFuZHk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gU3VuLCBBcHIgMTAsIDIwMTYgYXQgNToyMiBBTSwgQ2Fyc3RlbiBCb3Jt YW5uIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Y2Fib0B0emkub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMAogICAgICAg ICAgICAgICAgICAuOGV4OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0 OjFleCI+DQpJbiBCdWVub3MgQWlyZXMsIHdlIGRpc2N1c3NlZCB0aGUgYWRvcHRpb24gb2Y8YnI+ DQpkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBidXQgbm90IGVub3Vn aCBwZW9wbGUgaGFkIHJlYWQ8YnI+DQp0aGUgZG9jdW1lbnQgdG8gZ28gZm9yIGFuIGluLXJvb20g Y29uc2Vuc3VzIGNhbGwuPGJyPg0KPGJyPg0KVGhpcyBpcyBhIHR3by13ZWVrIGNhbGwgZm9yIGFk b3B0aW9uIG9mPGJyPg0KZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAg YXMgYSBXRyBkb2N1bWVudCBvZiBDb1JFLjxicj4NClNwZWNpZmljYWxseSwgaWYgeW91ICgxKSBz dXBwb3J0IG9yICgyKSBoYXZlIGFuIG9iamVjdGlvbiB0byB0aGlzPGJyPg0KZGVjaXNpb24sIHBs ZWFzZSBzcGVhayB1cCBvbiB0aGUgbWFpbGluZyBsaXN0IGJ5IDIwMTYtMDQtMjQuPGJyPg0KPGJy Pg0KTm90ZSB0aGF0IHRoaXMgd29yayBpcyBleHBsaWNpdGx5IGNvdmVyZWQgYnkgb3VyIGNoYXJ0 ZXIsIHNvIGRpc2N1c3Npb25zPGJyPg0Kb2Ygd2hpY2ggV0cgc2hvdWxkIHdvcmsgb24gdGhpcyBh cmUgb2ZmLXRvcGljLjxicj4NCjxicj4NCkFzIGFsd2F5cywgYWRvcHRpb24gb2YgYSBkb2N1bWVu dCBhcyBhIFdHIGRvY3VtZW50IGlzIG5vdCBhIHZvdGUgb248YnI+DQp3aGV0aGVyIHdlIGFscmVh ZHkgaGF2ZSByZWFjaGVkIGxhc3QtY2FsbCBzdGF0ZTsgdGhlIGludGVudGlvbiBpcyB0bzxicj4N Cndvcmsgb24gdGhlIFdHIGRvY3VtZW50IGFmdGVyIGFkb3B0aW9uIGZvciBhIHdoaWxlIHRvIGdl dCBpdCByZWFkeSBmb3I8YnI+DQpsYXN0IGNhbGwuJm5ic3A7IElmIHlvdSB3YW50IHRvIGNvbWJp bmUgeW91ciBzdXBwb3J0L29iamVjdGlvbiB3aXRoIHRlY2huaWNhbDxicj4NCmNvbW1lbnRzLCB0 aGlzIGlzIGNlcnRhaW5seSB3ZWxjb21lIHNvIHdlIGNhbiBhY2NlbGVyYXRlIHRoYXQgcHJvY2Vz cy48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3JlPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNp cGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQg aW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJ Zg0KIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1 bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVy J3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBp cyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHNjYW4gb3INCiBvdGhlcndpc2UgY2hlY2sgdGhpcyBl LW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4gPGJyPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0 YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4gPGJyPg0KPHByZT5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpjb3JlIG1haWxpbmcgbGlzdAo8YSBjbGFzcz0i bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29y ZUBpZXRmLm9yZzwvYT4KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+CjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LiBUaGV5IG1heSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGlu IGFueSB3YXkgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gSWYN CiB0aGlzIGUtbWFpbCBpcyByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1l bnRzLiBQbGVhc2Ugbm90ZSB0aGF0IG5laXRoZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidz IGNvbXBhbnkgYWNjZXB0IGFueSByZXNwb25zaWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMg eW91ciByZXNwb25zaWJpbGl0eSB0byBzY2FuIG9yDQogb3RoZXJ3aXNlIGNoZWNrIHRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR06MB18395917B148B4900842F399FC6E0VI1PR06MB1839eurp_-- From nobody Wed Apr 20 23:14:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C9212D1A9 for ; Wed, 20 Apr 2016 23:14:34 -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] 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 LpK2slmyKtMT for ; Wed, 20 Apr 2016 23:14:33 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D56F12D698 for ; Wed, 20 Apr 2016 23:14:33 -0700 (PDT) Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id B65EE41C09B; Thu, 21 Apr 2016 08:14:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ryOHSO3NEG_i; Thu, 21 Apr 2016 08:14:30 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 5D41441C088; Thu, 21 Apr 2016 08:14:29 +0200 (CEST) Message-ID: <57186FC3.9010405@tzi.org> Date: Thu, 21 Apr 2016 08:14:27 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Alexey Melnikov References: <5707D6F8.40000@isode.com> In-Reply-To: <5707D6F8.40000@isode.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: core@ietf.org Subject: Re: [core] Incoming AD review of draft-ietf-core-block-19 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:14:35 -0000 Alexey Melnikov wrote: > Hi, > I am mostly happy with this document, but I have a few comments/questions: > > On page 11: > > Clients that want to retrieve > all blocks of a resource SHOULD strive to do so without undue delay. > > This is not an interoperability issue and it would be impossible to > verify compliance with it, unless you have a number that specifies what > is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here. > Just use lowercased "should" instead. Indeed, you cannot measure compliance with this SHOULD. I still think that it is important for interoperability to point out that clients will have more successful exchanges if they heed this. (From an interoperability point of view, this is a statement that relieves servers of a potential onus to somehow cater for clients that don't.) > Similarly, in 2.5: > > Clients SHOULD strive to send all blocks of a > request without undue delay. > > (Similar text in 2.6) (Ditto.) > In 2.9.2: > > Should probably also mention that this response code is also used for > mismatching content-format options That is one way to see this; section 2.3 takes the view that mismatching content-formats aren't reassembled into one body in the first place so an incomplete body is the result of not having all parts. (I added back reference in the editor's draft.) > In 2.10: > > A response with a Block1 Option in control usage > with the M bit set invalidates cached responses for the target URI. > > Can you explain the reason for this? If the M bit had not been set the response would have been a final response and would be used to update the cache entries for this URI. Now, with the M bit set, we know that there will be a final response later, but we don't know what that will be. Continuing to serve a previous response from the cache doesn't sound right. But then, it could be argued that the server just promised to perform the request atomically later, so nothing has happened yet. Good question. > > In 3.2: > > A stateless server that simply builds/updates the resource in place > (statelessly) may indicate this by not setting the more bit in the > response (Figure 8); in this case, the response codes are valid > separately for each block being updated. > > What is the behaviour of both the client and the server if PUT on a > particular block fails? Is this clear enough in the document? In the stateless case, the resource is now probably broken (unless the resource is somehow intrinsically robust to this case). The client should not be using the resource (e.g., try to initiate a firmware update from an image it just has been building). The server is stateless with respect to individual requests, so it is patiently sitting there for the broken resource to be mended. > Other questions I have after reviewing the document. If I missed where > they are answered, please point me out to existing text in the document > or another RFC: > > Is there a special error for block size mismatch between multiple requests? A block size mismatch is not an error (maybe I don't understand the question). > As block2 is a critical option, how can a server know if a particular > client supports this option? The assumption here is that CoAP clients generally do, unless they are very specialized and never have to deal with non-trivial amounts of information (such as a /.well-known/core). Grüße, Carsten From nobody Wed Apr 20 23:37:18 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A0012E2EC for ; Wed, 20 Apr 2016 23:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9DUO-dwR0rv for ; Wed, 20 Apr 2016 23:37:12 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADA712E29D for ; Wed, 20 Apr 2016 23:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OcAckmoUMF/v6q6AMb4Oe5O9r8EEAlTLTHNpv2gs7ik=; b=pHHkE58yDyQx0idKGz+1Wswn+Tga6tCnjbM16tCSQx6obKk2danwWUej5ytOSuMN9ETrSfWErfTCk66kybe7hxDcKxBob2c21lBhKVhusCq256J92AT9SPNRsBf1BnejMcsPdtyMBtT6qTAxUUYxpEC0htt32knfBSTwrcNmrD4= Received: from AM3PR04CA0043.eurprd04.prod.outlook.com (10.242.16.43) by DB5PR04MB1575.eurprd04.prod.outlook.com (10.164.38.141) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 06:36:50 +0000 Received: from DB3FFO11FD013.protection.gbl (2a01:111:f400:7e04::170) by AM3PR04CA0043.outlook.office365.com (2a01:111:e400:8814::43) with Microsoft SMTP Server (TLS) id 15.1.466.19 via Frontend Transport; Thu, 21 Apr 2016 06:36:44 +0000 Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (23.103.247.132) by DB3FFO11FD013.mail.protection.outlook.com (10.47.216.187) with Microsoft SMTP Server (TLS) id 15.1.472.8 via Frontend Transport; Thu, 21 Apr 2016 06:36:44 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 21 Apr 2016 06:36:43 +0000 Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0453.032; Thu, 21 Apr 2016 06:36:43 +0000 From: "Dijk, Esko" To: "core@ietf.org WG" Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRkyOyNHdD2wIVlEuh1rqfQpAB2J+TEn0AgAAFBwCAAPH6AA== Date: Thu, 21 Apr 2016 06:36:43 +0000 Message-ID: <0fa1a5ae53764e0dba1dc1d31b6aca46@HE1PR9001MB0170.MGDPHG.emi.philips.com> References: <570A4583.2030100@tzi.org>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.209.152] Content-Type: multipart/alternative; boundary="_000_0fa1a5ae53764e0dba1dc1d31b6aca46HE1PR9001MB0170MGDPHGem_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(428002)(189002)(377454003)(199003)(85714005)(24454002)(189998001)(107886002)(110136002)(1220700001)(3846002)(102836003)(16236675004)(6116002)(586003)(24736003)(1096002)(230783001)(790700001)(5890100001)(66066001)(87936001)(108616004)(19625215002)(92566002)(450100001)(86362001)(10400500002)(512874002)(106116001)(33646002)(11100500001)(3900700001)(2906002)(101416001)(5003600100002)(19617315012)(16796002)(2950100001)(81166005)(2900100001)(105586002)(229383001)(84326002)(6806005)(19580405001)(19580395003)(50986999)(76176999)(54356999)(19300405004)(5004730100002)(5008740100001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR04MB1575; H:011-smtp-out.Philips.com; FPR:; SPF:None; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD013; 1:LRnTshmleTZYjnDJCFqzEtPW00bBNahK7PB9/f/6WG1Q2mBNhqnAI+f12np2wkZRiS/ywR4dAntKe5hLGjnLktdEiTiQXzwdOrVIdXSyAO6FywuZNRlTr5J3k7vDtdv2vmKy4k/pqrwsVHpo6PRrNFCBwYcxoOWr4RDBsFhYaJK5eOmlwnPFxi1+ZJToXSLn/RYALlyGfDnZR9ouvC3XGzJbXOAC5/xdZYyS+nDvnQ36rjoFh9YSHJpIensEeb6ndIiMfDslbflG/+YG0hEcnwwiweWqJCmDGI1AZ4BbbDLpn02BIpUwwzUi0qCvkDhm+ETgu2Wk16CHUA9q+7HJeV8WX1AhZWVEhEImqpmYiIqwjxvmtGC4tEX21hlxBBQRa5YFjKJQLhtNL5T588EqWAIpT4GrLfFzkqlR/PNjPNbqSmKUwyRTgDHaRqNtMkBH X-MS-Office365-Filtering-Correlation-Id: 4149c495-4e68-401a-d48f-08d369af4e7d X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1575; 2:53jvx92Lmha9cvAO8yKeVd/EbWfRvA7/K2OI2J07QmoLbAUmCbwS0oDI16iwWuRrEGV+H5yf6aEB2NzFlRqF/mXB+ysQVDFRUIvEmvA86Ya0KfzPSxDSXn6W8EIzjNGe1+vxtqir5f6CeG/Bvw/bR6vGY6+N1fOtVAP5DiI56vmUCMo8dfBUozPKoEbrYYqw; 3:82SsyanZX0aMPWfmPFQ2SVDBg7KQt2WBj3vNWFdECn9hTBmBK4h1ryUq6PlbaBV9M9ZZ9qtTC8/vGSg1aGm0ud6+wotN8hFVsG0IASncaneL789e/doHC+CMBU6WO8mAeAOhUteV46D1oP27yMTYrf/7CdSZnNR/bU/TGJKxjCSiI+deO0QX7IhhFsbQJIxX5YTm5mZr1+xYpWP8W5QesmK2I9oBVArcDhroDWEVDMs=; 25:24EeKuUK0lsDr3anmkwIxsxoL2mULlcOiTZgyNP27Mn4P4JS/0Cvfvbsb0xdYRXbEnK1dL/NmWFg7E95fMGAlJxJnsUtbM/GwhQU9FH19gb2+uRZhmLjgr8rLmEBVYn+CatrQVm83kbFt2kkdLNIReG01F4QAUklngFObP11gx9qt1UEOynibAsdLq0Fssui2aQv5akkLUzliE6OYtDOmPtHmHFOH7Zp3WoQurNupAr7CsZBhDroFdOzbkV4RBsqbEkEjDla21AsGvGQLwR1pOe4/1YiuqVrd3eTVqEojCp/5M5GM1nUF2GeUQhnTwup1RC/vV825TqOZmoUkjcMLw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1575; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1575; 20:ZyfBZH0C+fBw4PfRdbj5FJij9x7jyC87pzFDPiEQsXslAzfocMndcmDYuXgVen2empCCkjCyxXlnDzvBGmAqvWK96c8JQR7Sef9tUa4jXr8LgnVdhCUZd3cEwzK8mwq47ckuBcm67EPsKQli3PiSBWJsf6x7xWFxoVpITiZIQfWbkucG8H6SXLYe/+xRVvF9u45Wuf9zCjyDtt7SXQjqjYnU8gCJ6ZmBMh0k8Bh0/48QJNx5cBWSwunVQ09CtL3wfweK7m03ef882VgsbbHSyr5LPFCjZ7hFHpmLozPnE2tYDV36p0Gcm41UO5fPN5oR7Kc5gg+VFCbvasp8W8NpCYpwjQOg/bdyOHBFvYuxtaOpOlTODFFM8LlXSJ5PBlcURDNwqpFmenOdT3efTOBGUf/NO+TvOolEeqCcM1lJ4wq9P1lhL3a+0aeOjrJGcnse1DQJkx6hzHmJ0bzFnaT3uzy/2xzctNG7n1NbABKetHOlit+h6FGKYJOdiYhwa/KU X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(13016025)(13018025)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DB5PR04MB1575; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1575; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1575; 4:v/qmSH3VibhFYPgBodoS3EalrG8ikmUtGBvJct5kgS3fbOUrrWzNixTMooOhuaTjy3COk8ANtq2WInDIxVqVk5+xI928Sq4HmVJCnrpL1P2lzdzaFufx9hyWaTLYyqHFnt8/VAkhpRMZEG4LbXMtOYwUO24Lff9wvjV/DT8yxC4j9BQ2Xe1LqZgBJzCk3gWMRtPQZgAvs1ViIDv25JXpILA1TR03bJ8hCf5/nEL6AMy3+tZKQpOFYW+nSUxlUUw26O1WsTzngcQ2bQ8aFjQ78O0anDfP1JjlrjKz7T552t61k36C0UypcK8UJ1Qmg8blXgAEbm0nnyWiEfTPR+S7C/0OhEMu6OPxUrkAJJNTcYnf8L7j5DDXYlNwfwzwK5rqHsDSSIjx/CJ0wIFtQ2jSb2WE1HrnLw68aminUVZo+TISEEnKadynEvRYfR6mkTQCtoagGtbgPRp7e1bS3nT4Vg== X-Forefront-PRVS: 091949432C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5PR04MB1575; 23:KEBRfGrjcb6eWereukiWpQgNWQFCwlBuWkJ8maYTh?= =?us-ascii?Q?CCru0q3tOhdAm8B+aQDItL6UI2X8ZtTrc+aaWwW+Phn7iC1M+3kK5oQBtENX?= =?us-ascii?Q?BOWs6SKsbiXPIR7ZlEshiG6Z2LV4BWqVm1X88JEDitRrhZQEIMmIJmDdvQpf?= =?us-ascii?Q?TIDopxOiy/NIyswrrxvN9rguSLAxbNeLCJYmq7Iumh6HM3xiJmYu7qRz92TX?= =?us-ascii?Q?EbLT8QqVhIJRCTSVVnB2ednaQZmJjND6OE22nSRJZtmtonRW+XwuGQg2BrRz?= =?us-ascii?Q?JzrLAfN22rT7NKl0Eh/bvhF4riA06bFZiKf0EEksVbSkakPHuIN6eiDSyBma?= =?us-ascii?Q?fzA+AlzjcgMhibIVz6w0DCdVRhTop3QoSV60F+Y8+StAVaYgtnwv1fcEHkOe?= =?us-ascii?Q?RzCoOifLhK1cA1kgIf9PHByiI9AdTpYh7MKxoraxL2ybXmIkwTU8rrAIpU7Z?= =?us-ascii?Q?hDnImTfpgYcE+1XYXJLn9CRyuWNjIq7wBQJ95rlIJWlUwxaA0QN6tWhNYfeu?= =?us-ascii?Q?5A+ukGjWAcsCOGldktoArS1FgZ3b/0maaEwMYlO1Vd6W5pmxJWSAFqPwrm8r?= =?us-ascii?Q?wyQVVKEmVitbLBd1Y32GUjrtNEAW4Ft90LGDaCTYC7DGObm62R02FvQNSFzL?= =?us-ascii?Q?PmO4S9P1Zwjf6mhPwaFrRFNer4MwZbjySDqWMIo/sXg+dB+6/QBpxXm8HLCY?= =?us-ascii?Q?R+SwgdIfa9oGIZbPhBFDY51cE1zNpkM4i6BBWarLjU/jhBxXz9HD2tvZDaf4?= =?us-ascii?Q?mmQ+PF5NnIz0TjznZW5U0VnjSf+nkFqm8xt6yUu2hNJvP+D4xJqD25U64v5x?= =?us-ascii?Q?cfSFborSilYCD8dg1jeKo7NILbFt5fmw28hZGFxHJ8tTX1i0nP8y1juhB+ZU?= =?us-ascii?Q?mZ6iOAC1vZkk+Pg0+WULt/LXJiS8eOg2rvy+6Yg5w54W8kmjX/MvljHqskAc?= =?us-ascii?Q?z4XqaeUL1EYc12hNwiKfzU1lCyJ8M+x+WC3zGK1cyr4Nm63+3RYacogYke9i?= =?us-ascii?Q?nGQkFqwTivlktw2w+W3mUxnEP/9ziH7M5ldv4FqiSwHfxo0aNjLR9BPIYFEx?= =?us-ascii?Q?bvEkoRcuclDYKUssGYkALBd5mWInmMsaRUN/xp+YaaenvQ4X2uEf+RxveEwl?= =?us-ascii?Q?Dr6mkn1uSe9+Rn51baxPaogS5r0sLTBBuPaBnR8DIKFYj8IoejAhX0sMPyNZ?= =?us-ascii?Q?76XjkfToYfibOVRhcgKxB8Q5CZ0OAKy+RyNjVhtICeuhx2flViH9rZQPY3jk?= =?us-ascii?Q?tt4tyVZEx9FjC4/tIJZwUOa49K9ofJLKvrjAHIJGQClP2tjPz6SybWJPZDud?= =?us-ascii?Q?oVmWsOySZuBlMs8Nu22Vbik3hU6ttfaLDz+H11e3jmzMkYtJoXIXHzmYJVG5?= =?us-ascii?Q?wQDWaTMzANDshVEfy5cSyWxIPZPQBktl1QpVH8lxx0FX+8/FeVmGN3LNXsGy?= =?us-ascii?Q?oTSuygV/5hPTiTRQ89BxXXTy4q92Y4=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1575; 5:jyeWn+syN+l2aRJsSwFfIAEqdY2FeQhuv2po9DpvMke8QerEgBPjFkTD0CJ8nU1s2epQkl/2ACi2u+nRf6L4ZGSRAyDMTYe5y2/CG/VeM5cIGaZpNPVTXEBYSBePaYbF0Z3HcPYDsMkH+0ZYfdnzWHFL9/JzPx55WUdB3kn4EuJ2MpXX2bP7r8VR61IC1CyZ; 24:Z4XyOZXC8iAcyz1Kp1sx6PgZAMbhIx9mN82EP+xLrxd1oTD1bjv+8G3RV3aXsjVybp5Aapax+z3oFEsfBDWLfq+VwDoW3OpT/lhx1XjmG2w=; 7:diezCTM8ZBCX8Q1nDyZzRuTqEzzcXRnO3bdyP78fd2LJSxaha5V28LRuTNdtpCIhK1uCGZztZ9ngyTl1xE7Qf7lOas6cN/p9/ulifO7BRjFSm4C7UEXapXcvgOuCgXaPtMZAlAC2KTg77uHjTmLVqyMp1D3Epw3UGJZ2g2kIfRaeoScTf5zsxWoH3xgD8ihe25rogVNtj+LFjVWjpb0rAyQPLA+7SfrffIRnOOrJS5s= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2016 06:36:44.4718 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1575 Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:37:14 -0000 --_000_0fa1a5ae53764e0dba1dc1d31b6aca46HE1PR9001MB0170MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgOyBhbHNvIGluIGZhdm9yIG9mIGFkb3B0aW9uIGZvciB0aGUgcHVycG9zZSB0aGF0IEFiaGlu YXYgbWVudGlvbnMuDQoNCkVza28gRGlqaw0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU29tYXJhanUgQWJoaW5hdg0KU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAyMCwgMjAxNiAxODowOQ0KVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y a3MuY29tPjsgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+DQpDYzogY29yZUBpZXRmLm9y ZyBXRyA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlv biBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMA0KDQoNCkhpLA0K DQpJIChhcyBhbiBhdXRob3IpIGFtIGluIGZhdm91ciBvZiBhZG9wdGlvbi4NCg0KDQoNCldlIHBs YW4gdG8gdXNlIFlhbmcgdG8gbW9kZWwgcmVzb3VyY2VzIGluIGxpZ2h0aW5nIGFuZCBidWlsZGlu ZyBhdXRvbWF0aW9uIGFwcGxpY2F0aW9ucyBhbmQgd2lsbCB1c2UgdGhlIFlhbmctQ2JvciBtYXBw aW5nIGRyYWZ0IHRvIHNwZWNpZnkgaG93IHRoZSBwYXlsb2FkIHdpbGwgYmUgZm9ybWF0dGVkIGlu IENCT1IgaW5zdGVhZCBvZiB1c2luZyBKU09OL1hNTCBzY2hlbWEgZGVmaW5pdGlvbnMuDQoNCg0K DQpBYmhpbmF2DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjb3Jl IDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjAsIDIwMTYgNTo1MCBQTQ0K VG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+IFdHDQpTdWJqZWN0OiBSZTogW2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVp bGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDANCg0KSGksDQoNCkkgYW0gaW4gZmF2b3Ig b2YgYWRvcHRpb24uDQpXZSBwbGFuIHRvIGltcGxlbWVudCB0aGlzIGRyYWZ0IGZvciB1c2Ugd2l0 aCBDb01JDQphbmQgcG9zc2libHkgUkVTVENPTkYuDQoNCg0KQW5keQ0KDQoNCk9uIFN1biwgQXBy IDEwLCAyMDE2IGF0IDU6MjIgQU0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0 bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCkluIEJ1ZW5vcyBBaXJlcywgd2UgZGlzY3Vzc2VkIHRo ZSBhZG9wdGlvbiBvZg0KZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAg YnV0IG5vdCBlbm91Z2ggcGVvcGxlIGhhZCByZWFkDQp0aGUgZG9jdW1lbnQgdG8gZ28gZm9yIGFu IGluLXJvb20gY29uc2Vuc3VzIGNhbGwuDQoNClRoaXMgaXMgYSB0d28td2VlayBjYWxsIGZvciBh ZG9wdGlvbiBvZg0KZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYXMg YSBXRyBkb2N1bWVudCBvZiBDb1JFLg0KU3BlY2lmaWNhbGx5LCBpZiB5b3UgKDEpIHN1cHBvcnQg b3IgKDIpIGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoaXMNCmRlY2lzaW9uLCBwbGVhc2Ugc3BlYWsg dXAgb24gdGhlIG1haWxpbmcgbGlzdCBieSAyMDE2LTA0LTI0Lg0KDQpOb3RlIHRoYXQgdGhpcyB3 b3JrIGlzIGV4cGxpY2l0bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciwgc28gZGlzY3Vzc2lvbnMN Cm9mIHdoaWNoIFdHIHNob3VsZCB3b3JrIG9uIHRoaXMgYXJlIG9mZi10b3BpYy4NCg0KQXMgYWx3 YXlzLCBhZG9wdGlvbiBvZiBhIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQgaXMgbm90IGEgdm90 ZSBvbg0Kd2hldGhlciB3ZSBhbHJlYWR5IGhhdmUgcmVhY2hlZCBsYXN0LWNhbGwgc3RhdGU7IHRo ZSBpbnRlbnRpb24gaXMgdG8NCndvcmsgb24gdGhlIFdHIGRvY3VtZW50IGFmdGVyIGFkb3B0aW9u IGZvciBhIHdoaWxlIHRvIGdldCBpdCByZWFkeSBmb3INCmxhc3QgY2FsbC4gIElmIHlvdSB3YW50 IHRvIGNvbWJpbmUgeW91ciBzdXBwb3J0L29iamVjdGlvbiB3aXRoIHRlY2huaWNhbA0KY29tbWVu dHMsIHRoaXMgaXMgY2VydGFpbmx5IHdlbGNvbWUgc28gd2UgY2FuIGFjY2VsZXJhdGUgdGhhdCBw cm9jZXNzLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxt YWlsdG86Y29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIFRoZXkgbWF5IG5v dCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQgaW4gYW55IHdheSBieSBhbnlv bmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBJZiB0aGlzIGUtbWFpbCBpcyBy ZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhlIGUtbWFpbCBhbmQgYXR0YWNoZWQgZG9jdW1lbnRzLiBQbGVhc2Ugbm90ZSB0 aGF0IG5laXRoZXIgdGhlIHNlbmRlciBub3IgdGhlIHNlbmRlcidzIGNvbXBhbnkgYWNjZXB0IGFu eSByZXNwb25zaWJpbGl0eSBmb3IgdmlydXNlcyBhbmQgaXQgaXMgeW91ciByZXNwb25zaWJpbGl0 eSB0byBzY2FuIG9yIG90aGVyd2lzZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxs eSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVk IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJk aW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4g ZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= --_000_0fa1a5ae53764e0dba1dc1d31b6aca46HE1PR9001MB0170MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgU3lt Ym9sIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+JiM0MzsxIDsgYWxzbyBpbiBmYXZvciBvZiBhZG9wdGlvbiBmb3IgdGhlIHB1cnBvc2UgdGhh dCBBYmhpbmF2IG1lbnRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Fc2tvIERpams8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Tb21hcmFqdSBBYmhpbmF2PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXByaWwgMjAsIDIwMTYgMTg6MDk8YnI+DQo8Yj5Ubzo8L2I+IEFuZHkgQmllcm1hbiAm bHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OzsgQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5v cmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBjb3JlQGlldGYub3JnIFdHICZsdDtjb3JlQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDss c2Fucy1zZXJpZiI+JiMxMjgyNzY7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFdHIGFkb3B0aW9u IG9mIGRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1tYXBwaW5nLTAwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPHAgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIChhcyBhbiBhdXRob3Ip IGFtIGluIGZhdm91ciBvZiBhZG9wdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldlIHBs YW4gdG8gdXNlIFlhbmcgdG8gbW9kZWwgcmVzb3VyY2VzIGluIGxpZ2h0aW5nIGFuZCBidWlsZGlu ZyBhdXRvbWF0aW9uIGFwcGxpY2F0aW9ucyBhbmQgd2lsbCB1c2UgdGhlIFlhbmctQ2JvciBtYXBw aW5nIGRyYWZ0IHRvIHNwZWNpZnkgaG93IHRoZSBwYXlsb2FkIHdpbGwgYmUgZm9ybWF0dGVkDQog aW4gQ0JPUiBpbnN0ZWFkIG9mIHVzaW5nIEpTT04vWE1MIHNjaGVtYSBkZWZpbml0aW9ucy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkFiaGluYXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9 Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5Rndk TXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiBjb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGll dGYub3JnIj5jb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBBbmR5 IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVt YXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjAs IDIwMTYgNTo1MCBQTTxicj4NCjxiPlRvOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uPGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4gV0c8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjb3JlXSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFw cGluZy0wMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBhbSBpbiBmYXZvciBvZiBhZG9wdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2UgcGxhbiB0byBpbXBs ZW1lbnQgdGhpcyBkcmFmdCBmb3IgdXNlIHdpdGggQ29NSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5hbmQgcG9zc2libHkgUkVTVENPTkYuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPk9uIFN1biwgQXByIDEwLCAyMDE2IGF0IDU6MjIgQU0sIENh cnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+SW4gQnVlbm9zIEFpcmVzLCB3ZSBkaXNjdXNzZWQgdGhlIGFkb3B0aW9u IG9mPGJyPg0KZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYnV0IG5v dCBlbm91Z2ggcGVvcGxlIGhhZCByZWFkPGJyPg0KdGhlIGRvY3VtZW50IHRvIGdvIGZvciBhbiBp bi1yb29tIGNvbnNlbnN1cyBjYWxsLjxicj4NCjxicj4NClRoaXMgaXMgYSB0d28td2VlayBjYWxs IGZvciBhZG9wdGlvbiBvZjxicj4NCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1tYXBw aW5nLTAwIGFzIGEgV0cgZG9jdW1lbnQgb2YgQ29SRS48YnI+DQpTcGVjaWZpY2FsbHksIGlmIHlv dSAoMSkgc3VwcG9ydCBvciAoMikgaGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhpczxicj4NCmRlY2lz aW9uLCBwbGVhc2Ugc3BlYWsgdXAgb24gdGhlIG1haWxpbmcgbGlzdCBieSAyMDE2LTA0LTI0Ljxi cj4NCjxicj4NCk5vdGUgdGhhdCB0aGlzIHdvcmsgaXMgZXhwbGljaXRseSBjb3ZlcmVkIGJ5IG91 ciBjaGFydGVyLCBzbyBkaXNjdXNzaW9uczxicj4NCm9mIHdoaWNoIFdHIHNob3VsZCB3b3JrIG9u IHRoaXMgYXJlIG9mZi10b3BpYy48YnI+DQo8YnI+DQpBcyBhbHdheXMsIGFkb3B0aW9uIG9mIGEg ZG9jdW1lbnQgYXMgYSBXRyBkb2N1bWVudCBpcyBub3QgYSB2b3RlIG9uPGJyPg0Kd2hldGhlciB3 ZSBhbHJlYWR5IGhhdmUgcmVhY2hlZCBsYXN0LWNhbGwgc3RhdGU7IHRoZSBpbnRlbnRpb24gaXMg dG88YnI+DQp3b3JrIG9uIHRoZSBXRyBkb2N1bWVudCBhZnRlciBhZG9wdGlvbiBmb3IgYSB3aGls ZSB0byBnZXQgaXQgcmVhZHkgZm9yPGJyPg0KbGFzdCBjYWxsLiZuYnNwOyBJZiB5b3Ugd2FudCB0 byBjb21iaW5lIHlvdXIgc3VwcG9ydC9vYmplY3Rpb24gd2l0aCB0ZWNobmljYWw8YnI+DQpjb21t ZW50cywgdGhpcyBpcyBjZXJ0YWlubHkgd2VsY29tZSBzbyB3ZSBjYW4gYWNjZWxlcmF0ZSB0aGF0 IHByb2Nlc3MuPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3Rlbjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvcmU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGll bnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3BpZWQgaW4g YW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCiByZWNpcGllbnQuIElm IHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBkb2N1bWVu dHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2VuZGVyJ3Mg Y29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBpdCBpcyB5 b3VyIHJlc3BvbnNpYmlsaXR5DQogdG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhpcyBlLW1h aWwgYW5kIGFueSBhdHRhY2htZW50cy4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxicj4NCjxo cj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVn YWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQNCiB0aGF0IGFueSB1c2UsIGZv cndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2Ug aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJl dHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2Fn ZS48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0fa1a5ae53764e0dba1dc1d31b6aca46HE1PR9001MB0170MGDPHGem_-- From nobody Wed Apr 20 23:40:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D212E39E; Wed, 20 Apr 2016 23:40:00 -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] 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 YZXpGZemxQNP; Wed, 20 Apr 2016 23:39:58 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A409712E1AC; Wed, 20 Apr 2016 23:39:58 -0700 (PDT) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 4538BA80C7; Thu, 21 Apr 2016 08:39:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id w2_D7C1U9h59; Thu, 21 Apr 2016 08:39:54 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 93F1EA80CB; Thu, 21 Apr 2016 08:39:53 +0200 (CEST) Message-ID: <571875B6.8070303@tzi.org> Date: Thu, 21 Apr 2016 08:39:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Stephen Farrell References: <20160419121034.31581.55883.idtracker@ietfa.amsl.com> In-Reply-To: <20160419121034.31581.55883.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:40:00 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > The intro and early section 2 has quite a bit of argument > as to why this design is good or better than some other. > For this reader, that's not really needed (I assume the WG > had those discussions). Indeed, this could have been cleaned out, but then having some rationale *why* things were done in some way is often helpful to the implementer. > I think this is an example of a > recurring problem with the text here - with too many words, > clarity suffers. For example the Implementation note on p7 > is, just by itself, the best and would be a sufficient > explanation of, the encoding, the description of which is > otherwise pretty opaque. There are some specifications out there that essentially give a canned implementation in prose. That runs into a problem when that prose is ambiguous (or wrong). So having some descriptive text as well is usually preferable. Some amount of redundancy may be useful (examples should always be redundant...). > There's also a good bit of > repetition that makes this a harder read in general. That's > all just IMO of course, and there may be history in the WG > that provides good cause for so many words to be needed. The history is that this specification was written long ago and updated as new information became available. No conscious decision to be overly verbose. > All that said, I assume that it's too late to reduce the > size of this document, so no action is required unless the > authors/WG/chairs would themselves like to try remove > words. As an author, I think it would have been good to have a major rewrite around 2013 when the concepts had become solid. Doing that now is a bit more dangerous than I like... (And we have already had enough delay in processing this.) Grüße, Carsten From nobody Thu Apr 21 00:01:32 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2FF12E9EE; Thu, 21 Apr 2016 00:01:25 -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] 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 IXDpt8Hcxxtu; Thu, 21 Apr 2016 00:01:23 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A754312E9E9; Thu, 21 Apr 2016 00:01:23 -0700 (PDT) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id B73D21720B2; Thu, 21 Apr 2016 09:01:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 5E76DHQBc5IF; Thu, 21 Apr 2016 09:01:19 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C06971720F3; Thu, 21 Apr 2016 09:01:17 +0200 (CEST) Message-ID: <57187ABB.7050301@tzi.org> Date: Thu, 21 Apr 2016 09:01:15 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mirja Kuehlewind References: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> In-Reply-To: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-block-19=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:01:26 -0000 Hi Mirja, > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is only a minor point, requesting to spell out implicit assumptions > explicitly. However, I think it's important to address this before > publication. > > It is not clear in the main part of the doc that this extension to does > not change the message transmission method as specified in RFC7252 > (Stop-and-wait retransmission). With my initial ready I assumed that this > extension would allow the sending of back-to-back messages. Only by > looking at the examples, it got clear to me that this is not the case. I'm wondering how we managed to create that expectation. As I said in the response to Spencer's comment, block-wise transfers are strictly layered on top of RFC 7252 CoAP. Maybe there is some introductory text needed that emphasizes this early on. Implementations that I know run completely lock-step. Theoretically, an implementation could pipeline requests for further blocks after the initial exchange (which needs to be lock-step so a common block-size can be determined; also, a Size2 option would be needed to determine the number of requests to be sent). NSTART (Section 4.7 of RFC 7252) puts a hard limit on the parallelism here, and the default value of NSTART (without advanced congestion control) is 1, so we are back to lock-step. > Further, this document does not say anything about reliability. Do block > message need to be transmitted reliable (as Confirmable)? If not, this > extension could still lead to back-to-back sending and then further > guidance on congestion control would be needed. Block-wise transfers can be sent in NON messages. That would not be a particularly wise choice in general, as the delivery probability for the whole body decreases exponentially (section 2.8 outlines one specific use case for using NON in the first block only, though). NON messages can not simply be sent back-to-back in CoAP, see section 4.7 of RFC 7252. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with others that reduncy makes the doc harder to read, especially > regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and > MUST in one section and combine the Usage guidance with the examples? The usage guidance (section 2.5?) is more normative than just an example. Moving all interoperability requirements into one section might create even more duplication of text. > Further, please also add a reference for ETag in section 2.4. I have added a reference to Section 5.10.6 of RFC 7252 in the editor's draft. Grüße, Carsten From nobody Thu Apr 21 00:45:08 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A4912E41E; Thu, 21 Apr 2016 00:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 2db5VwEBpaQ9; Thu, 21 Apr 2016 00:45:00 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FA512E164; Thu, 21 Apr 2016 00:44:59 -0700 (PDT) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 3EDF11720D1; Thu, 21 Apr 2016 09:44:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tagLITSUwzff; Thu, 21 Apr 2016 09:44:26 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6B6241720A4; Thu, 21 Apr 2016 09:44:25 +0200 (CEST) Message-ID: <571884D7.7080206@tzi.org> Date: Thu, 21 Apr 2016 09:44:23 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ben Campbell References: <20160419032438.11079.43000.idtracker@ietfa.amsl.com> In-Reply-To: <20160419032438.11079.43000.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 07:45:02 -0000 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be easy to clean up, and it's entirely possible I am > misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be > inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading the > following: (Section 2.4, I presume.) > 1. If the client requests a specific block size, the server MUST use that > size or a smaller one. Yes, that is the negotiation logic. > 2. Any subsequent requests from the client MUST indicate the same size > that the server used (If the Block2 option was given in the first request.) > 3. But paragraph 3 then says all further requests SHOULD indicate the > same size. But if they already MUST indicate the same size as in the > initial response, then this SHOULD seems non-constraining at best, and > at worst in conflict with 1. (ignoring the last-block size issue for the > moment.) This is for the general case, including the one where the Block2 option came in as a surprise for a request without a Block2 option. The client might want to adjust that block size down again in its second request (the first one with a Block2 request option). But the SHOULD is unfortunate, because the sentence is really describing the likely outcome and not a mandate on the client behavior. > 4. Then paragraph 3 goes on to say the server SHOULD use the block size > indicated in the request or smaller. This seems to conflict with the MUST > in 1. That is indeed an unfortunate construction (with the "or"). > 5. Then it again asserts that the client MUST indicate the same size in > subsequent requests, conflicting with the SHOULD in 3., but agreeing with > the MUST in 1. Thank you for noticing this jumble; to be cleaned up in the next draft. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > - General: The draft dives into detail without giving much context until > the examples. The reader is left to infer the forest from the trees. It > would be very helpful (to me, at least) to add a high-level overview of > operation early in the document, including definitions for "descriptive" > vs " control" usages. (I know it's late in the process to ask for a whole > new section, so I won't push the point.) Others have already been complaining about too much text... > - The distinction between the option names Block1 and Block2 seems almost > actively non-mnemonic. Is that intentional? (I won't push this point, > either.) Go ahead and invent better ones... We tried. (Block1 is for the bodies in the requests, which are the first messages in an exchange, Block2 for bodies in the responses, which are the second messages in an exchange.) > - 3.4: Does the eTag apply to the "payload" or the whole "body"? To the body. We say this explicitly for the Content-Format, but not for ETag; we probably should. I have added text to the penultimate paragraph of Section 2 in the editor's draft. > - 2.5, 2nd paragraph, last sentence: > Should I read this to mean that the reduction in block size is > retroactive? That could use some elaboration. (I thought I read comments > in the examples suggesting such a reduction would _not_ be retroactive). The transfer that already happened used a certain block size, and that history of course doesn't change. The last sentence points out that if the next transfer uses a different (smaller) block size, the block number needs to be scaled up so we hit the right continuation point. > - 7: Does "object security" apply to the "payload", or the "body"? Yes. That is the discussion we are having in defining object security extensions. Both may be useful (actually, it may be even better to define a third level between "payload" and "body" which defines the slices to be secured independently). > Can you describe or add a reference for the "usual considerations"? For Buffer Overflows? Good question. Is there a canonical reference for that? (If the reader doesn't already know about buffer overflows, maybe they shouldn't be implementing protocols?) > Editorial: > > - Abstract: That’s a really long abstract, and serves more as an > introduction than an abstract. Please consider combining the first and > last paragraph and leaving the rest to the introduction. Actually, I consider this to be a quite useful abstract -- many RFC abstracts are too short to be really useful as an abstract (as in "why should I be reading this document" and "if I don't read it, do I still know what it is about"). It hasn't been through the "leave out every third word" filter yet, but, hey, it fits on the first page :-) There is a larger discussion about RFC style lurking here; maybe this isn't the place. > - 2.4, paragraph 5: a definition for "reassembler" would be helpful. Maybe it's easier to simply s/client's reassembler/client/. Done in editor's draft. > - Figures 5 and 6: > There's no discussion of either figure. Is that intentional? Is discussion beyond the introductory paragraph on page 18 needed? (Students typically found these figures self-explanatory.) Grüße, Carsten From nobody Thu Apr 21 01:10:15 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C2712DA62 for ; Thu, 21 Apr 2016 01:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 z27YSouBZ-FJ for ; Thu, 21 Apr 2016 01:10:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 6DEF812DA41 for ; Thu, 21 Apr 2016 01:10:11 -0700 (PDT) Received: from localhost ([::1]:48106 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1at9gf-0006kU-5e; Thu, 21 Apr 2016 01:10:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org X-Trac-Project: core Date: Thu, 21 Apr 2016 08:10:09 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/398 Message-ID: <066.78a2d4a690a4650c0e11c6cfcb53c260@trac.tools.ietf.org> X-Trac-Ticket-ID: 398 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #398 (resource-directory): lighting example X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:10:12 -0000 #398: lighting example Example is too extensive and needs to separate DNS-SD part from rest of example. -- ----------------------------------------+-------------------------------- Reporter: consultancy@vanderstok.org | Owner: peter van der Stok Type: editorial | Status: new Priority: major | Milestone: Component: resource-directory | Version: Severity: Active WG Document | Keywords: lighting example ----------------------------------------+-------------------------------- Ticket URL: core From nobody Thu Apr 21 01:13:45 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C68312E07A for ; Thu, 21 Apr 2016 01:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 BUGaH1CyFs_3 for ; Thu, 21 Apr 2016 01:13:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 990AD12E466 for ; Thu, 21 Apr 2016 01:13:40 -0700 (PDT) Received: from localhost ([::1]:48164 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1at9k4-0007wT-HC; Thu, 21 Apr 2016 01:13:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org X-Trac-Project: core Date: Thu, 21 Apr 2016 08:13:40 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/399 Message-ID: <066.238820fc3c09fb38b50d80e817f7008d@trac.tools.ietf.org> X-Trac-Ticket-ID: 399 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: [core] #399 (resource-directory): message exchange figures X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:13:44 -0000 #399: message exchange figures remove message exchange figures -- ----------------------------------------+-------------------------------- Reporter: consultancy@vanderstok.org | Owner: peter van der Stok Type: editorial | Status: new Priority: major | Milestone: Component: resource-directory | Version: Severity: Active WG Document | Keywords: ----------------------------------------+-------------------------------- Ticket URL: core From nobody Thu Apr 21 01:15:34 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC212E86F for ; Thu, 21 Apr 2016 01:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 iHz3SOu4Ks0L for ; Thu, 21 Apr 2016 01:15:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D274B12E757 for ; Thu, 21 Apr 2016 01:15:31 -0700 (PDT) Received: from localhost ([::1]:48204 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1at9lr-0005tV-NE; Thu, 21 Apr 2016 01:15:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: consultancy@vanderstok.org X-Trac-Project: core Date: Thu, 21 Apr 2016 08:15:31 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/383#comment:1 Message-ID: <076.732d4c6cde40e3a578df3e96e668217b@trac.tools.ietf.org> References: <061.d17fb56c1d21a605f555f84d62caba2e@trac.tools.ietf.org> X-Trac-Ticket-ID: 383 In-Reply-To: <061.d17fb56c1d21a605f555f84d62caba2e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: consultancy@vanderstok.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: core@ietf.org Subject: Re: [core] #383 (resource-directory): HTTP response codes missing for function set definitions X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Reply-To: trac+core@zinfandel.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:15:33 -0000 #383: HTTP response codes missing for function set definitions Changes (by consultancy@vanderstok.org): * status: new => closed * resolution: => fixed -- ---------------------------------+----------------------------------------- Reporter: | Owner: consultancy@vanderstok.org esko.dijk@philips.com | Status: closed Type: protocol defect | Milestone: Priority: major | Version: Component: resource-directory | Resolution: fixed Severity: - | Keywords: | ---------------------------------+----------------------------------------- Ticket URL: core From nobody Thu Apr 21 02:43:05 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9615512E850 for ; Thu, 21 Apr 2016 02:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 8Girtc-_xyiv for ; Thu, 21 Apr 2016 02:43:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B240412E83F for ; Thu, 21 Apr 2016 02:43:00 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ld1CS-1bb0HJ1ZL6-00iC2h; Thu, 21 Apr 2016 11:42:49 +0200 To: Carsten Bormann , "core@ietf.org WG" References: <570A4583.2030100@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5718A09E.7040607@gmx.net> Date: Thu, 21 Apr 2016 11:42:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570A4583.2030100@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VM93EAiJjFCLoHuBtBaSXvF0XJ1Kl3Fdc" X-Provags-ID: V03:K0:tbybjx22tKluzkatBsYwGs0zPwGU83XK11QV30bDWhGqJ+Y2yRp qQlKpwzk6MvYNkq7B64MLekQIOP/unnIFQOhHboef3Z8D2wE1/2T6sTK6gHUzqyJJ1hLQeE Uehov3x1KKyuzGDA9WL0uvX28wMas9McKDO6cws8BbOhci66J/Dc63F/nzhl5nb+eXyeuqs 5W31L+aalaDOUaW0IE3Uw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5gRn7UM/Hl8=:AYcr5s+uS+FUnUwnr9uGpg aXpUrVpw+SmSZ8ociwl+UMy/4NsxgEyawg4XL8NtRNjGpV0jUhFqmnL/YBJ4NG9OAY/uKw4uU 9LPONPICX1rCiVktdf093XuNREGr3VVn+gXt2xQ98f/LED+NTFw2Lxy4v1PZa8tFBKHx/ePqR ny2n4HAf0+yZJrQhdBG+b2igjUDfy/GNmHP6tDIlldU3SdmGc7SwQC4Vye8vSmXogglSzBnoa GxkHn+JfDi12QnOu+5Agz1b8qKc+1CkvxS9qH5ofCIIvSUwHyUzAHQddBlW1R1vEWW8reQL+e XwzAWXpz8gmEA6U5sjMqcxbG35l4X2uulm7+mDwzs+QjUDTd6OJAo6akt5SIr0Y2MsW3vFI+8 5G5LcpvPYJyo7YdTvfhvDmHNRO14h0n6k7DzE4gl2ExjMVd10VebD/Wtq7Y+/7XZ+gQAK/JeT Eau+eovEjHE0zD60K2fr5jN9c6NL2Bz6f1wU2urJAvsa4jmQCmeSXLQR4wPAbUVLLhKgatYAf Li9cb+ZCPqk+aHnpjiOaHKvRtKqPWQ8whS4Jxf2+BN16ssGdrFgFLDrFjC1kUhtGk/6M2/Q+x ZpAokd+Gh7yVnR3AkHgyvQ9L+tPot9t9fkdO5QYFY8ZCETLtzvV6mt87OMRdkd5fj1p3cGwsE Qzjiqw0eExKlp+/w5IFrzhAehYAJDAL4kgbLC1dqbo6jET0Oume1BOMU07zOxm8yTLc242ejg PIfu2n+38cZuRSiYIoQetsNbULgOo3Fyathd2FVwtrzid0L0Jz9U/E3SXuc= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 09:43:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VM93EAiJjFCLoHuBtBaSXvF0XJ1Kl3Fdc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Hi all, I think we are going to fast here. We hardly make any progress with the existing WG items but then we add a number of new items that are barely understood. This call for adoption is not a call for this document this is a question whether we want to work on the following two types of things: a) a data modelling language (Yang) for use with IoT objects (which in case of IoT are largely defined elsewhere), and b) re-use a protocol machinery originally defined for network management around Netconf (which may now be converted to CoAP and CBOR usage). I have spent some time trying to figure out what the implications are and (that's a bold statement) doubt that most WG participants (except for the authors of the documents) really understand what this really mean= s. Here are the claims: 1) IoT will re-use many of the objects defined for network management. 2) There is a need for a formal language to describe the data model. 3) There is a value in generating code using that formal data model description. 4) Yang (as a data modelling language) and the related protocols are a good match for the requirements people have. Are these claims actually true? Given that we are late at the party and other organizations have done a fair amount of work in that space already I am wondering whether we have done our home work of analysis the existing landscape or whether we are just interested to add another set of standards to the mix. I have my opinion about the claims and I would like to share them with yo= u. Regarding (1) on the re-use argument. I do not believe that the existing, already standardized objects defined for network management are a good fit for what we are doing in IoT. I have not seen the examples where there is re-use. As illustrated below, I am exposing my sensors, buttons, and LEDs to outside world rather than network interfaces and alike. I fully understand that the world is far more complex with routers and switches that have many ports and lots of configuration parameters. They are also running regular operating systems, like Linux. Regarding (2) on the use of formal languages. It seems that most organizations are using formal languages for describing their object definitions already today. I personally believe that these formal languages do not provide a lot of value in general but using something that is easy for humans to write and read is something I may be OK with. Particularly the example below shows that all I need as a developer is very little. IoT devices typically do not have many sensors and the implementation complexity is elsewhere (with the operating system, the tool chain, and various low power settings). Regarding (3) on the value of code generation. I am currently in the process of writing a new tutorial for a developer workshop hosted by the Open Mobile Alliance (OMA), see http://openmobilealliance.org/free-hands-on-training-for-iot-developers-w= ith-oma-lwm2m-and-arm-based-microprocessors/ I am using regular IoT hardware, namely the K64F board with onboard sensors, namely an accelerometer and magnetometer, an RGB LED, and two buttons. The sensors are connected using I2C and are certainly not among the most simplistic (which the data sheet of almost 100 pages can easily tell you). In the process of writing code I need to do the following: * Figure out how to connect to the sensors using I2C. * Learn how the sensor works, how to configure the sensor to do what I want, and to convert the raw sensor data into something suitable for my application. One can only hope to find a library that does these things already and to only have to adjust the settings rather than writing everything from scratch. That typically takes a lot of time. * Determine whether is a suitable object definition already available. In my case I am looking at the OMNA registry (which has also been populated with the objects from the IPSO Alliance). Here are the registered objects: http://technical.openmobilealliance.org/Technical/technical-information/o= mna/lightweight-m2m-lwm2m-object-registry In case of the Accelerometer and the Magnetometer I am lucky since those have already been defined. I don't need to define my own objects, which is a simple task given the new OMA object editor http://devtoolkit.openmobilealliance.org/OEditor/Default * Then, I need to add the code for use with them. Here is where the formal description of the data model could help me to automatically produce code. Now, this is the funny thing: this code amounts for around 5 lines, depending on the API and programming language you are using. Most likely the code generation will produce some code that you cannot directly use. Here is what I have to write on the IoT side: ---- // Create object '3313' =3D 'Accelerometer' acc_object =3D M2MInterfaceFactory::create_object("3313"); M2MObjectInstance* acc_inst =3D acc_object->create_object_instance(); M2MResource* acc_x_res =3D acc_inst->create_dynamic_resource("5702", "X Value",M2MResourceInstance::FLOAT, true /* observable */); M2MResource* acc_y_res =3D acc_inst->create_dynamic_resource("5703", "Y Value",M2MResourceInstance::FLOAT, true /* observable */); M2MResource* acc_z_res =3D acc_inst->create_dynamic_resource("5704", "Z Value",M2MResourceInstance::FLOAT, true /* observable */); ----- I fear that we are optimizing for something that does not take a long time anyway. It will take longer to fetch the relevant Yang file, to use the tools to generate the code and to integrate it into the existing code than to just write these few lines yourself. What the above example does not utilize potential code generation for the actual interaction model. In my case my code is hard-wired to use LWM2M. Since I have not yet seen a meaningful example of Yang for the IoT environment I also haven't seen one that produces meaningful code for the interaction model either. Regarding (4) concerning Yang as a data modelling language (vs. other languages also considered by the IoT communities). As Paul noted there are other languages in town and I personally do not know whether the features offered by Yang are better or equal to those offered by the other languages. I certainly haven't done that analysis. As a concluding remark I would like to say that while my current assessment may sound negative I am happy to learn more about this topic and might get convinced that Yang is the right tool. Currently, I just haven't reached that level yet and I can claim that I have spent some time looking at this topic already. Ciao Hannes On 04/10/2016 02:22 PM, Carsten Bormann wrote: > In Buenos Aires, we discussed the adoption of > draft-veillette-core-yang-cbor-mapping-00 but not enough people had rea= d > the document to go for an in-room consensus call. >=20 > This is a two-week call for adoption of > draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. > Specifically, if you (1) support or (2) have an objection to this > decision, please speak up on the mailing list by 2016-04-24. >=20 > Note that this work is explicitly covered by our charter, so discussion= s > of which WG should work on this are off-topic. >=20 > As always, adoption of a document as a WG document is not a vote on > whether we already have reached last-call state; the intention is to > work on the WG document after adoption for a while to get it ready for > last call. If you want to combine your support/objection with technica= l > comments, this is certainly welcome so we can accelerate that process. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --VM93EAiJjFCLoHuBtBaSXvF0XJ1Kl3Fdc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXGKCeAAoJEGhJURNOOiAtnbsH/2yKCrHipqcdSVsnZSAXIZxW xjEfT3WI94yQ5QRP1ZjPb536JQTAHsKkUx456cTauMT3/d1HBFUZq112YTu07fRE QAlTEdSCK1zY04KDdeMKrwVIw3cAv04Xe1ftN992JI8MEEtrwKYwwNnddWB5iDRl ffgMjC5a4CtE7EGyNR6NyHc+LDeh1apiNErv+CSLabpc9x2wK4ghdCcaTME6nVdV 1xHd+sOBR0v04mnhdPxSpYxsx4I9qwKXmGAg18cQNvZvnYk16aGwKPBJ7a+DybN4 d/pDuNzzZoVf6p90VchhOgU6kVX0oUaOpksD1o1dlhGiEUVAtQ9HdEY3t5XQj7M= =qiVc -----END PGP SIGNATURE----- --VM93EAiJjFCLoHuBtBaSXvF0XJ1Kl3Fdc-- From nobody Thu Apr 21 05:32:29 2016 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 9EC4012DD73; Thu, 21 Apr 2016 05:32:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421123228.19614.44752.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 05:32:28 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, bill.wu@huawei.com, core@ietf.org Subject: [core] Benoit Claise's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:32:28 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- CoAP is based on datagram transports such as UDP, which limit the maximum size of resource representations that can be transferred without creating unreasonable levels of IP fragmentation. CoAP is based on UDP, right? So isn't it? NEW: CoAP is based on UDP datagrams, which limit the maximum size of resource representations that can be transferred without creating unreasonable levels of IP fragmentation. And ... OLD: Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (such as UDP), NEW: Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (UDP), Note that they might exist other instances. From nobody Thu Apr 21 05:41:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B81E12EC19; Thu, 21 Apr 2016 05:41:48 -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] 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 ibcMftFuB0o6; Thu, 21 Apr 2016 05:41:39 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C0D12EC22; Thu, 21 Apr 2016 05:41:39 -0700 (PDT) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 6F0A7A80C8; Thu, 21 Apr 2016 14:41:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id d9p_IuWm_nEk; Thu, 21 Apr 2016 14:41:36 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7E5E7A8102; Thu, 21 Apr 2016 14:41:34 +0200 (CEST) Message-ID: <5718CA7C.4090205@tzi.org> Date: Thu, 21 Apr 2016 14:41:32 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Benoit Claise References: <20160421123228.19614.44752.idtracker@ietfa.amsl.com> In-Reply-To: <20160421123228.19614.44752.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org, bill.wu@huawei.com Subject: Re: [core] Benoit Claise's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:41:48 -0000 Hi Benoit, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > CoAP is based on datagram transports such as UDP, which limit the > maximum size of resource representations that can be transferred > without creating unreasonable levels of IP fragmentation. > > CoAP is based on UDP, right? So isn't it? > NEW: > CoAP is based on UDP datagrams, which limit the > maximum size of resource representations that can be transferred > without creating unreasonable levels of IP fragmentation. CoAP is often run on DTLS (which is then generally run on UDP, but can also be run on, say, SMS). > And ... > > OLD: > Using fragmentation (either at the adaptation layer or at > the IP layer) for the transport of larger representations would be > possible up to the maximum size of the underlying datagram protocol > (such as UDP), > > NEW: > Using fragmentation (either at the adaptation layer or at > the IP layer) for the transport of larger representations would be > possible up to the maximum size of the underlying datagram protocol > (UDP), > > Note that they might exist other instances. I think the generality here is warranted; as UDP is indeed by far the most important underlying protocol, we are only discussing that one, so the cost of that generality is low. Grüße, Carsten From nobody Thu Apr 21 05:48:42 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECE312D778; Thu, 21 Apr 2016 05:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6mi4_0Ps5O4; Thu, 21 Apr 2016 05:48:39 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A3412E051; Thu, 21 Apr 2016 05:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1634; q=dns/txt; s=iport; t=1461242919; x=1462452519; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J/n8YTtrRU5LOJMaMwkKwPTaXzzwIJBqvkp3i6rMvqY=; b=jqHUJfMzhT9Wn5tP4igRHDg1OeLpUrPv1aEunuGeOzttE9kKUm8OazdU b+EVPM57QgsWPEgqetHCi2NX71LPsEPXRU3XLwEvOI0ThgflwbDeDXDko 2Q9Clq1VRhn2E1gW/6BcPd7AoAjnjaXRa33Ym9H8K11LJGAlcobHQ2r1s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBABeyxhX/xbLJq1evGiED4YOAoF6A?= =?us-ascii?q?QEBAQEBZieEQgEBBCMPAQVAARAJAg4MAgUWCwICCQMCAQIBRQYKAwgBAYgmkQe?= =?us-ascii?q?dF5EaAQEBAQEBAQECAQEBAQEBARl8hSWES4QagyWCVgEEh3SQG44UiTmFV48tY?= =?us-ascii?q?oIzgTc6hzuBPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,512,1454976000"; d="scan'208";a="635287815" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 12:48:36 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3LCmaq9021368; Thu, 21 Apr 2016 12:48:36 GMT To: Carsten Bormann References: <20160421123228.19614.44752.idtracker@ietfa.amsl.com> <5718CA7C.4090205@tzi.org> From: Benoit Claise Message-ID: <5718CC24.2090208@cisco.com> Date: Thu, 21 Apr 2016 14:48:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5718CA7C.4090205@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org, bill.wu@huawei.com Subject: Re: [core] Benoit Claise's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 12:48:40 -0000 Hi Carsten, Am I correct that rfc7252 only specifies UDP (and DTLS)? Regards, Benoit. > Hi Benoit, > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> CoAP is based on datagram transports such as UDP, which limit the >> maximum size of resource representations that can be transferred >> without creating unreasonable levels of IP fragmentation. >> >> CoAP is based on UDP, right? So isn't it? >> NEW: >> CoAP is based on UDP datagrams, which limit the >> maximum size of resource representations that can be transferred >> without creating unreasonable levels of IP fragmentation. > CoAP is often run on DTLS (which is then generally run on UDP, but can > also be run on, say, SMS). > >> And ... >> >> OLD: >> Using fragmentation (either at the adaptation layer or at >> the IP layer) for the transport of larger representations would be >> possible up to the maximum size of the underlying datagram protocol >> (such as UDP), >> >> NEW: >> Using fragmentation (either at the adaptation layer or at >> the IP layer) for the transport of larger representations would be >> possible up to the maximum size of the underlying datagram protocol >> (UDP), >> >> Note that they might exist other instances. > I think the generality here is warranted; as UDP is indeed by far the > most important underlying protocol, we are only discussing that one, so > the cost of that generality is low. > > Grüße, Carsten > > . > From nobody Thu Apr 21 06:09:52 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B6B12DAF4; Thu, 21 Apr 2016 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqKFcrrJltHK; Thu, 21 Apr 2016 06:09:45 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 C9CC212D73F; Thu, 21 Apr 2016 06:09:44 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g133so77657877ywb.2; Thu, 21 Apr 2016 06:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WuSDQl8Za9YfV+r+csYgyRwKhsPLpbEj8zmwVRlxYgE=; b=FLBnw8WV2NKYGuLUsOtTdMtSCEEBCRfbd8ESru/u4HzuLNfCXb/s2nctlfk5C4mF66 ctR8ZZTgxiTB493GXl3Io/HE0nIWiN5dckK+XnCS8OSW9n7khM85glAPQE1vk0734lkT IWTQMo7hmXQOAIdLqK2sg62G2r3VXAsoIFjefRgEvZ0XBo4jwD3RkmH5tq3KV6paEz/s HhwZW7tlYq7YV3hSb7IC8k8LVvlNkh/PGZ4IBFmcFZWPEZ+MoscGKlmOgMoEzVBOL+/7 FLm7R7yb/ys87Jtcp2IFcnDWdboD/zzOcPiaDHAgeJ+ezBAMfrqFEZ+nRx8J8vxgf9BF o1nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WuSDQl8Za9YfV+r+csYgyRwKhsPLpbEj8zmwVRlxYgE=; b=B3XaPnjisyVn9/EGak/eb6yl4xME3KYXzJcXfUUOxmiLO/b4i/fiD9dttntoV/ZQ6+ EgZBvz08fgXVYpyCTeRdj50X8R62vJpsBqp5yHXDZoPqEZPefhGghhi5FUGdIWfA/6IB eyb1r5C3Hia18jsN3Awhzh0qjOdCl8y6ba8dBQ0LcjxzpGiOPOiA4Ef0OqVunPdsN5km gAW9W8GD71Tr+xDpl3gde6XWEuqC1MRPO0rlD75JhdPIz5lgdtk0knxko2ryZUkIFdit rXuEYY0DH/vS5Cb+ItATYX2Gr9zgIseZfgh0nE2bkagX4OyIhNdypYP1MJ2ClVjUMJfh M6GA== X-Gm-Message-State: AOPr4FUY6Z7gAzf/0wFHGehXmZkn1NoHm5UFWz82KUlRKlV14hEEdaDs5HZJMGjv33M+jWCx7AaJBs5sH57gmQ== MIME-Version: 1.0 X-Received: by 10.13.226.149 with SMTP id l143mr5276832ywe.294.1461244184030; Thu, 21 Apr 2016 06:09:44 -0700 (PDT) Received: by 10.37.224.212 with HTTP; Thu, 21 Apr 2016 06:09:43 -0700 (PDT) In-Reply-To: <571864D3.2000906@tzi.org> References: <20160418044805.28780.94432.idtracker@ietfa.amsl.com> <571864D3.2000906@tzi.org> Date: Thu, 21 Apr 2016 08:09:43 -0500 Message-ID: From: Spencer Dawkins at IETF To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a114fbd0684f8470530fe6c6d Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , "core@ietf.org" Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:09:47 -0000 --001a114fbd0684f8470530fe6c6d Content-Type: text/plain; charset=UTF-8 Hi, Carsten, On Thu, Apr 21, 2016 at 12:27 AM, Carsten Bormann wrote: > Hi Spencer, > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please consider whether you need to say more about UDP usage for this > > extension than what the base CORE specification says - RFC 7252 has only > > one mention of RFC 5405, and that only points to guidance about reducing > > ACK_TIMEOUT below one second. I understand that the CoAP story includes > > "most of these nodes aren't capable of generating a lot of packets in a > > short timeframe", but does this extension make it easier to send multiple > > UDP packets back-to-back? > > The block-wise specification does not say anything about congestion > control because it strictly layers on top of RFC 7252 and uses the > congestion control specification there (Section 4.7). Back-to-back > packets are limited by that section (NSTART as a limit for initiating > exchanges, PROBING_RATE as a limit for sending with no response). > > Block-wise transfers cannot send/solicit more traffic than a client > could be sending to the same server without the block-wise mode. My problem was that I didn't understand from the text that the same method of pacing packets that contained complete requests was being used to pace packets that contained blocks. I think that I can derive what you're saying from the draft, but it wasn't clear to me. I saw that in the thread of Mirja's Discuss, you suggested adding this point more explicitly. That would solve my issue here. > > I'm reading this text, > > > > In most cases, all blocks being transferred for a body (except for > > the last one) will be of the same size. > > > > and then this text > > > > * The block size implied by SZX MUST match the size of the > > payload in bytes, if the M bit is set. (SZX does not govern > > the payload size if M is unset). For Block2, if the request > > suggested a larger value of SZX, the next request MUST move SZX > > down to the size given in the response. (The effect is that, > > if the server uses the smaller of (1) its preferred block size > > and (2) the block size requested, all blocks for a body use the > > same block size.) > > > > and realizing that I'm confused about why all the blocks for a body might > > NOT use the same block size. Maybe this doesn't matter (because an > > implementation would need to be prepared for the case when all the blocks > > don't use the same block size)? > > The first request may be using a block size that is larger than what the > server prefers. That is one case where the block size changes during a > whole transfer. See also Figure 4 for an example where the client > prefers a smaller block size than the server sent initially. > > So, yes, an implementation needs to be prepared for cases where at least > the initial block is of a different size than the following (full) > blocks. I believe this is evident to the implementers at least from the > examples. That's very helpful. Would it be correct to say (in the first paragraph I included above) something like In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. If the first request uses a bigger block size than the receiver prefers, subsequent requests will use the preferred block size. just so you're not relying on implementers to figure out what to implement solely from the examples? Thanks, Spencer --001a114fbd0684f8470530fe6c6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Carsten,

On Thu, Apr 21, 2016 at 12:27 AM, Carsten Bormann <cabo@tzi.org= > wrote:
Hi Spencer,

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Please consider whether you need to say more about UDP usage for this<= br> > extension than what the base CORE specification says - RFC 7252 has on= ly
> one mention of RFC 5405, and that only points to guidance about reduci= ng
> ACK_TIMEOUT below one second. I understand that the CoAP story include= s
> "most of these nodes aren't capable of generating a lot of pa= ckets in a
> short timeframe", but does this extension make it easier to send = multiple
> UDP packets back-to-back?

The block-wise specification does not say anything about congestion<= br> control because it strictly layers on top of RFC 7252 and uses the
congestion control specification there (Section 4.7).=C2=A0 Back-to-back packets are limited by that section (NSTART as a limit for initiating
exchanges, PROBING_RATE as a limit for sending with no response).

Block-wise transfers cannot send/solicit more traffic than a client
could be sending to the same server without the block-wise mode.

My problem was that I didn't understand from the = text that the same method of pacing packets that contained complete request= s was being used to pace packets that contained blocks. I think that I can = derive what you're saying from the draft, but it wasn't clear to me= .

I saw that in the thread of Mirja's Discuss,= you suggested adding this point more explicitly. That would solve my issue= here.
=C2=A0
> I'm= reading this text,
>
>=C2=A0 =C2=A0 In most cases, all blocks being transferred for a body (e= xcept for
>=C2=A0 =C2=A0 the last one) will be of the same size.
>
> and then this text
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 The block size implied by SZX MUST m= atch the size of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 payload in bytes, if the M bit is se= t.=C2=A0 (SZX does not govern
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the payload size if M is unset).=C2= =A0 For Block2, if the request
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 suggested a larger value of SZX, the= next request MUST move SZX
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 down to the size given in the respon= se.=C2=A0 (The effect is that,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if the server uses the smaller of (1= ) its preferred block size
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and (2) the block size requested, al= l blocks for a body use the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 same block size.)
>
> and realizing that I'm confused about why all the blocks for a bod= y might
> NOT use the same block size. Maybe this doesn't matter (because an=
> implementation would need to be prepared for the case when all the blo= cks
> don't use the same block size)?

The first request may be using a block size that is larger than what= the
server prefers.=C2=A0 That is one case where the block size changes during = a
whole transfer.=C2=A0 See also Figure 4 for an example where the client
prefers a smaller block size than the server sent initially.

So, yes, an implementation needs to be prepared for cases where at least the initial block is of a different size than the following (full)
blocks.=C2=A0 I believe this is evident to the implementers at least from t= he
examples.

That's very helpful.=C2=A0

Would it be correct to say (in the first paragraph I= included above) something like

=C2=A0 =C2=A0 In most c= ases, all blocks being transferred for a body (except for
=C2=A0=C2=A0 =C2=A0the last one) will be of the same size.= If the first request uses a bigger
=C2=A0 = =C2=A0 block size than the receiver prefers, subsequent requests will use
=C2=A0 =C2=A0 the preferred block size.

just so yo= u're not relying on implementers to figure out what to implement solely= from the examples?

Thanks,

Spencer
--001a114fbd0684f8470530fe6c6d-- From nobody Thu Apr 21 06:41:31 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EB212DF1B; Thu, 21 Apr 2016 06:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlU5DtbDQ4V2; Thu, 21 Apr 2016 06:41:28 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F7A12DEBD; Thu, 21 Apr 2016 06:41:27 -0700 (PDT) Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 6A63141C0A6; Thu, 21 Apr 2016 15:41:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 95Y3SP0EC50i; Thu, 21 Apr 2016 15:41:23 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id E03B041C0B0; Thu, 21 Apr 2016 15:41:01 +0200 (CEST) Message-ID: <5718D86C.3000702@tzi.org> Date: Thu, 21 Apr 2016 15:41:00 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Benoit Claise References: <20160421123228.19614.44752.idtracker@ietfa.amsl.com> <5718CA7C.4090205@tzi.org> <5718CC24.2090208@cisco.com> In-Reply-To: <5718CC24.2090208@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org, bill.wu@huawei.com Subject: Re: [core] Benoit Claise's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:41:29 -0000 Benoit Claise wrote: > Hi Carsten, > > Am I correct that rfc7252 only specifies UDP (and DTLS)? That is correct. RFC 7252 also has a lot of this generality-infused text, as in: 3. Message Format CoAP is based on the exchange of compact messages that, by default, are transported over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP, or SCTP, the specification of which is out of this document's scope. (UDP-lite [RFC3828] and UDP zero checksum [RFC6936] are not supported by CoAP.) (One transport that we are working on right now is TLS and/or TCP; the block-wise protocol is used here both to avoid head-of-line blocking and to stay compatible with the message sizes RFC 7252 recommends based on UDP/DTLS.) Grüße, Carsten From nobody Thu Apr 21 06:58:19 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824FF12E313; Thu, 21 Apr 2016 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 PomQzac31tX4; Thu, 21 Apr 2016 06:58:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EED0112DD62; Thu, 21 Apr 2016 06:58:02 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3LDw1lX027347 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 21 Apr 2016 08:58:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Carsten Bormann" Date: Thu, 21 Apr 2016 08:58:01 -0500 Message-ID: <2F5D6BEB-C3DB-48C3-A0A0-DC56EEAB7643@nostrum.com> In-Reply-To: <571884D7.7080206@tzi.org> References: <20160419032438.11079.43000.idtracker@ietfa.amsl.com> <571884D7.7080206@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org Subject: Re: [core] Ben Campbell's Discuss on draft-ietf-core-block-19: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 13:58:05 -0000 On 21 Apr 2016, at 2:44, Carsten Bormann wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This should be easy to clean up, and it's entirely possible I am >> misreading something. But Section 3.4, 2nd and 3rd paragraph seem to >> be >> inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading >> the >> following: > > (Section 2.4, I presume.) > >> 1. If the client requests a specific block size, the server MUST use >> that >> size or a smaller one. > > Yes, that is the negotiation logic. > >> 2. Any subsequent requests from the client MUST indicate the same >> size >> that the server used > > (If the Block2 option was given in the first request.) > >> 3. But paragraph 3 then says all further requests SHOULD indicate the >> same size. But if they already MUST indicate the same size as in the >> initial response, then this SHOULD seems non-constraining at best, >> and >> at worst in conflict with 1. (ignoring the last-block size issue for >> the >> moment.) > > This is for the general case, including the one where the Block2 > option > came in as a surprise for a request without a Block2 option. The > client > might want to adjust that block size down again in its second request > (the first one with a Block2 request option). But the SHOULD is > unfortunate, because the sentence is really describing the likely > outcome and not a mandate on the client behavior. > >> 4. Then paragraph 3 goes on to say the server SHOULD use the block >> size >> indicated in the request or smaller. This seems to conflict with the >> MUST >> in 1. > > That is indeed an unfortunate construction (with the "or"). > >> 5. Then it again asserts that the client MUST indicate the same size >> in >> subsequent requests, conflicting with the SHOULD in 3., but agreeing >> with >> the MUST in 1. > > Thank you for noticing this jumble; to be cleaned up in the next > draft. Thanks, I will release the DISCUSS now, but will watch for the update. > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive: >> >> - General: The draft dives into detail without giving much context >> until >> the examples. The reader is left to infer the forest from the trees. >> It >> would be very helpful (to me, at least) to add a high-level overview >> of >> operation early in the document, including definitions for >> "descriptive" >> vs " control" usages. (I know it's late in the process to ask for a >> whole >> new section, so I won't push the point.) > > Others have already been complaining about too much text... Others have complained about duplication; that's not what I'm asking for. (In fact, I agree with them). In any case, this was a non-blocking comment. > >> - The distinction between the option names Block1 and Block2 seems >> almost >> actively non-mnemonic. Is that intentional? (I won't push this point, >> either.) > > Go ahead and invent better ones... We tried. (Block1 is for the > bodies > in the requests, which are the first messages in an exchange, Block2 > for > bodies in the responses, which are the second messages in an > exchange.) Again, a non-blocking comment. But how about Block-Req and Block-Resp? (or Req-block and Resp-block)? Those are obvious enough that I suspect people have already discarded them for some reason... > >> - 3.4: Does the eTag apply to the "payload" or the whole "body"? > > To the body. We say this explicitly for the Content-Format, but not > for > ETag; we probably should. I have added text to the penultimate > paragraph of Section 2 in the editor's draft. Thanks > >> - 2.5, 2nd paragraph, last sentence: >> Should I read this to mean that the reduction in block size is >> retroactive? That could use some elaboration. (I thought I read >> comments >> in the examples suggesting such a reduction would _not_ be >> retroactive). > > The transfer that already happened used a certain block size, and that > history of course doesn't change. The last sentence points out that > if > the next transfer uses a different (smaller) block size, the block > number needs to be scaled up so we hit the right continuation point. I think I understand. A bit of elaboration might help. > >> - 7: Does "object security" apply to the "payload", or the "body"? > > Yes. That is the discussion we are having in defining object security > extensions. Both may be useful (actually, it may be even better to > define a third level between "payload" and "body" which defines the > slices to be secured independently). > >> Can you describe or add a reference for the "usual considerations"? > > For Buffer Overflows? Good question. Is there a canonical reference > for that? (If the reader doesn't already know about buffer overflows, > maybe they shouldn't be implementing protocols?) I'm not aware of one --I was hoping you knew of some citable guidance :-) It's not a big deal if there's not one. > >> Editorial: >> >> - Abstract: That’s a really long abstract, and serves more as an >> introduction than an abstract. Please consider combining the first >> and >> last paragraph and leaving the rest to the introduction. > > Actually, I consider this to be a quite useful abstract -- many RFC > abstracts are too short to be really useful as an abstract (as in "why > should I be reading this document" and "if I don't read it, do I still > know what it is about"). It hasn't been through the "leave out every > third word" filter yet, but, hey, it fits on the first page :-) > > There is a larger discussion about RFC style lurking here; maybe this > isn't the place. Probably not. I won't push the matter. > >> - 2.4, paragraph 5: a definition for "reassembler" would be helpful. > > Maybe it's easier to simply s/client's reassembler/client/. > Done in editor's draft. works for me. > >> - Figures 5 and 6: >> There's no discussion of either figure. Is that intentional? > > Is discussion beyond the introductory paragraph on page 18 needed? > (Students typically found these figures self-explanatory.) > It's fine as it is if that is on purpose. Thanks! Ben. From nobody Thu Apr 21 07:09:14 2016 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 3529612DAAB; Thu, 21 Apr 2016 07:09:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160421140904.19594.51871.idtracker@ietfa.amsl.com> Date: Thu, 21 Apr 2016 07:09:04 -0700 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: [core] Ben Campbell's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:09:13 -0000 Ben Campbell has entered the following ballot position for draft-ietf-core-block-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-block/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I moved the following from a DISCUSS to a COMMENT, pending the next revision: -- START: This should be easy to clean up, and it's entirely possible I am misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading the following: 1. If the client requests a specific block size, the server MUST use that size or a smaller one. 2. Any subsequent requests from the client MUST indicate the same size that the server used 3. But paragraph 3 then says all further requests SHOULD indicate the same size. But if they already MUST indicate the same size as in the initial response, then this SHOULD seems non-constraining at best, and at worst in conflict with 1. (ignoring the last-block size issue for the moment.) 4. Then paragraph 3 goes on to say the server SHOULD use the block size indicated in the request or smaller. This seems to conflict with the MUST in 1. 5. Then it again asserts that the client MUST indicate the same size in subsequent requests, conflicting with the SHOULD in 3., but agreeing with the MUST in 1. -- END Substantive: - General: The draft dives into detail without giving much context until the examples. The reader is left to infer the forest from the trees. It would be very helpful (to me, at least) to add a high-level overview of operation early in the document, including definitions for "descriptive" vs " control" usages. (I know it's late in the process to ask for a whole new section, so I won't push the point.) - The distinction between the option names Block1 and Block2 seems almost actively non-mnemonic. Is that intentional? (I won't push this point, either.) - 3.4: Does the eTag apply to the "payload" or the whole "body"? - 2.5, 2nd paragraph, last sentence: Should I read this to mean that the reduction in block size is retroactive? That could use some elaboration. (I thought I read comments in the examples suggesting such a reduction would _not_ be retroactive). - 7: Does "object security" apply to the "payload", or the "body"? Can you describe or add a reference for the "usual considerations"? Editorial: - Abstract: That’s a really long abstract, and serves more as an introduction than an abstract. Please consider combining the first and last paragraph and leaving the rest to the introduction. - 2.4, paragraph 5: a definition for "reassembler" would be helpful. - Figures 5 and 6: There's no discussion of either figure. Is that intentional? From nobody Thu Apr 21 07:49:01 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5412D8C3; Thu, 21 Apr 2016 07:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 2wM9vCgYsL61; Thu, 21 Apr 2016 07:48:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9BD12D13B; Thu, 21 Apr 2016 07:48:52 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LvlTo-1bn7nJ0n9A-017XsP; Thu, 21 Apr 2016 16:48:41 +0200 To: Ben Campbell , The IESG References: <20160421140904.19594.51871.idtracker@ietfa.amsl.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5718E849.4000406@gmx.net> Date: Thu, 21 Apr 2016 16:48:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160421140904.19594.51871.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BXOwkL5AN28Q4Ag7ipwdcRJC7kWVFEaqV" X-Provags-ID: V03:K0:QiPKB9kuntpEcD/Tx9dyBzgQpZnxYfvRZMECAnH+/yWApEqF6lV Sbrpll8zycgojLoMmzDJqC+/ejJ/NMb+X8l9/22IQodSPGGAg5mtKjHq9GdUgzlCDBLYSnE 6QWbFV0e5sfJO5oFiZPv/kNVfQS97qPXvPskAHdd6L2p9NBANjfLxdjW5LH3g/heHQAHvku Rr8V+pInOadBYRvW5zASg== X-UI-Out-Filterresults: notjunk:1;V01:K0:jwBIdu1Q39Y=:8o/WwRbEh1fz1h4ukgWtcR W87Ak18N8Nfoqf4Q9jZD4vtZ5EA+MfxlVhj2kVX/o5wDExbfyCwB9ZZ+N0wFs5GyimobCFNSy +xQBzbKFxI0QzPiGqAnOuu89ws3u23ANXyEouLuz4Fju2XeDkDcs9GtQPUcXDP9rBKrEAqGxW PKTZjPUNg1ZOF8I/ddexZ+EwJZI1yd2rM9vCSzkhAXpa40inJFprZlHvi4JAsSIv5i2dp44gc h0eo9hyCrZpeed6hRxqA4m3QSOxiFcK7EUomQNbhEuvdk5yvZBRKMFd1c2nijTiyfswdrYjQD 8lEGpRk/u+e9eYScDd64vCls3ySPelZNdNt93iwsLmIRok2HjzuW8FMS2duk9SIIIBIFSxzwB OACfVpwonS1FQ6TSguWfgl3eu1GAO5czGUauE1Hkt0v4MmB4YzjiIUB0IYwb5LMCtiHgl6kMk zNc/cJ5uDHJfa6OCzGpStGSTNFLwzGG9YLssBmcox9+wqpLkF6K6pPy6GLYj3avwF+3h/kPhH QWQwxmL3cDuoPhh48t3vqpIKzYfk7qZJjKJRshP+Y7SoLbGpy3NtDSDIdtMP7TYogqwg0svoy sN9DlLSFVHZ57g+JbjU5UALfzo0CitolMoQFq9+t6qLR2pWsctP/crsxdHR4ibOlvUcHIU5RC wUF5eiO7YWRX/0B9pJckdt/SQ/tCqO3L+vEllUtfG9+p/+hPrN3L3KUz9/IpPI51n2+zWSTrk E6zD/RXozeSqdMSa447oePXbdP7SP+BhEcxecN3TEMwtN4UGqYdjfJr4ztA= Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, core@ietf.org Subject: Re: [core] Ben Campbell's No Objection on draft-ietf-core-block-19: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:48:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BXOwkL5AN28Q4Ag7ipwdcRJC7kWVFEaqV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ben, I agree with your statements about the need for an overview and the use of the Block1 and Block2 mnemonics. The Block1/Block2 functionality is heavily overloaded and really only best understood when looking at the examples. Conceptually, this is a fairly simple mechanism but the way it is written makes it sound somewhat complex. Ciao Hannes On 04/21/2016 04:09 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-core-block-19: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-block/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I moved the following from a DISCUSS to a COMMENT, pending the next > revision: >=20 > -- START: > This should be easy to clean up, and it's entirely possible I am > misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be= > inconsistent in SHOULD vs MUST for block size. I _think_ I'm reading t= he > following: >=20 > 1. If the client requests a specific block size, the server MUST use th= at > size or a smaller one.=20 >=20 > 2. Any subsequent requests from the client MUST indicate the same size > that the server used >=20 > 3. But paragraph 3 then says all further requests SHOULD indicate the > same size. But if they already MUST indicate the same size as in the > initial response, then this SHOULD seems non-constraining at best, an= d > at worst in conflict with 1. (ignoring the last-block size issue for th= e > moment.) >=20 > 4. Then paragraph 3 goes on to say the server SHOULD use the block size= > indicated in the request or smaller. This seems to conflict with the MU= ST > in 1. >=20 > 5. Then it again asserts that the client MUST indicate the same size i= n > subsequent requests, conflicting with the SHOULD in 3., but agreeing wi= th > the MUST in 1. >=20 > -- END >=20 >=20 > Substantive: >=20 > - General: The draft dives into detail without giving much context unti= l > the examples. The reader is left to infer the forest from the trees. It= > would be very helpful (to me, at least) to add a high-level overview of= > operation early in the document, including definitions for "descriptive= " > vs " control" usages. (I know it's late in the process to ask for a who= le > new section, so I won't push the point.) >=20 > - The distinction between the option names Block1 and Block2 seems almo= st > actively non-mnemonic. Is that intentional? (I won't push this point, > either.) >=20 > - 3.4: Does the eTag apply to the "payload" or the whole "body"? >=20 > - 2.5, 2nd paragraph, last sentence: > Should I read this to mean that the reduction in block size is > retroactive? That could use some elaboration. (I thought I read comment= s > in the examples suggesting such a reduction would _not_ be retroactive)= =2E >=20 > - 7: Does "object security" apply to the "payload", or the "body"? > Can you describe or add a reference for the "usual considerations"? >=20 > Editorial: >=20 > - Abstract: That=E2=80=99s a really long abstract, and serves more as a= n > introduction than an abstract. Please consider combining the first and > last paragraph and leaving the rest to the introduction. >=20 > - 2.4, paragraph 5: a definition for "reassembler" would be helpful. >=20 > - Figures 5 and 6: > There's no discussion of either figure. Is that intentional? >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --BXOwkL5AN28Q4Ag7ipwdcRJC7kWVFEaqV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXGOhLAAoJEGhJURNOOiAt0goH/jvjsQexTKxW+RgRtzBVF4AG +dNPLTIHO4Qi/zwPOPPojC+mb2OyFIeQ4nfFBj6tBICHdCfwI5KEbenW9WePwCUW 6e5zhvr3D1fEJH8CfhWEF78Ayo7GNPfijgPcnROTu0qzRKgO4aS+UIcJFnP8OMc0 f0h9fVKlOKOIDAnAdCr3W573ssU9vHsgBnI2ORk2jHVwr8HITOXt3j2L/CPrUF5U vcrSUd08GKTaM5+hkVcNdVIv22+l6i7h14V5IpifoYHSYsH81oMqOTk9NAJQSDRS aorKmrRSZq0hJs4NKgrcEh9ach+Cve74wykDopCGRtvn5PbZL/dsUTugSEzd5xM= =xWTU -----END PGP SIGNATURE----- --BXOwkL5AN28Q4Ag7ipwdcRJC7kWVFEaqV-- From nobody Thu Apr 21 08:35:35 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415E12E4CC for ; Thu, 21 Apr 2016 08:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-luebeck.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB9MRhiI3EUg for ; Thu, 21 Apr 2016 08:35:31 -0700 (PDT) Received: from ip1.rz.uni-luebeck.de (ip1.rz.uni-luebeck.de [141.83.100.71]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DB212E3E5 for ; Thu, 21 Apr 2016 08:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-luebeck.de; s=uzl; h=to:from:subject:message-id:date:mime-version; bh=tiD3Du0gAHGXEuR1xogy/i0HUtzH3mPpJkWAcBnO5Qk=; b=UuY9u5wvHChwPPt9mkDByJ2wL64kZKVNfWvBs8QbXzTmjPdSN7lSfnGj gzUirbAJECHpSqKQhmKPMVmODPR1hca/DO95mMQN10x+EAtkjORJGRnrh zEJT7vGJVOD8ekhXJ0q+yEak4HsVsYCR3LlSZ5j3U0kS6bHFt8MjogUV1 tpH9XKoFPtoMv+97B7ys5zyTOsKxLTclV2Q2X33i4on0bZ/qskxYmBG85 xYq+E2WM51TvHgCHvU9D4H8hMcoQ3u7jUiY/2SyweiLpjPZAAxRPSrT7i oa1UVrEENVXMmmIJnD8CsQ63Ry3yIsVTcu8FhsuhH3p4jXpaSPkxbWUL7 A==; IronPort-PHdr: =?us-ascii?q?9a23=3AlTIFDRNm+68lDrQZYyEl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0KP/zrarrMEGX3/hxlliBBdydsKIUzbSG+PCxEUU7or+/81k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZv?= =?us-ascii?q?IaytQ8iJ35TxibD5q8ybSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf?= =?us-ascii?q?9d32JiKAHbtR/94sCt4MwrqHwI6Lpyv/JHBK79ZakQTLFEAnIhKW9mytfssEzk?= =?us-ascii?q?SQqR62FUcWEbkxxFS1zG6Bz7WJrZszf/8Pd72WyeIMD8QLs3HzivufQ4ACT0gT?= =?us-ascii?q?sKYmZquFrcjdZ92fpW?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CzBADP8RhX/2REU41ehAtcuh6Bcx6HX?= =?us-ascii?q?RMBAQEBAQEBAWQngi2CPlU9FgsCBAcDAgECAVgIAQGIKgqebo9dkT4EBI93gjS?= =?us-ascii?q?CVgWYD4MogWZtiWkBh2QEhVePLSIBP4E2DIIoiWABAQE?= X-IPAS-Result: =?us-ascii?q?A2CzBADP8RhX/2REU41ehAtcuh6Bcx6HXRMBAQEBAQEBAWQ?= =?us-ascii?q?ngi2CPlU9FgsCBAcDAgECAVgIAQGIKgqebo9dkT4EBI93gjSCVgWYD4MogWZti?= =?us-ascii?q?WkBh2QEhVePLSIBP4E2DIIoiWABAQE?= Received: from itm01.itm.uni-luebeck.de (HELO mail.itm.uni-luebeck.de) ([141.83.68.100]) by ip1.rz.uni-luebeck.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2016 17:35:27 +0200 Received: from [141.83.68.39] (belladonna.itm.uni-luebeck.de [141.83.68.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.itm.uni-luebeck.de (Postfix) with ESMTPSA id 30C1483F8E4 for ; Thu, 21 Apr 2016 17:35:27 +0200 (CEST) To: core@ietf.org From: Oliver Kleine Message-ID: <5718F33E.9000103@itm.uni-luebeck.de> Date: Thu, 21 Apr 2016 17:35:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000704070908080508050500" Archived-At: Subject: [core] LUA script for CoAP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:35:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000704070908080508050500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, while implementing and testing the blockwise extension I realized, that there is no support for these options in Wireshark. I'm using the Wireshark version from Ubuntu LTE repositories (1.10.6). Thus, I implemented a Wireshark dissector for CoAP that supports the block options (see https://github.com/okleine/coap-lua). Maybe this is helpful for others, too. The script can be easily adjusted to listen at TCP port 5683 (or any other) for CoAP over TCP. Best, Oliver --------------ms000704070908080508050500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC D+cwggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBVcwggQ/oAMCAQICBxev9uxcqeowDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA2MDUxNDA2MjFaFw0xOTA3MDkyMzU5MDBa MHsxCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEnMCUG A1UEAxMeQ0EgZGVyIFVuaXZlcnNpdGFldCB6dSBMdWViZWNrMSEwHwYJKoZIhvcNAQkBFhJw a2lAdW5pLWx1ZWJlY2suZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCWZS7m r7XjjwizbKXx3HQYxk369Bw40r31jGlnN0lJl2e+VCzKa2KOSGndQ2dfPEFfGTS16BEhpf8S PPYDPEsMz8WR/FnZdFGK4qpV0b7+pzN7L4xgnKoG2LXWaJR2hygCb6fG2EiPWT7eovN4PK/s NXj/5ekPfXdyKrD9fbMPhll+mTTR9DsCypH5oDGOFAsNAn3h0iE4dYPTl67T3LGhYl7Wd7Z9 zSZRfD6a+lOmJ86jguBL1rfq5wvefwIvsGZYYwOTf+uZyMosFYZlGMJCY0m9JO/ZNoRGdDGd v1iFVSxeL0im28gZzoREaPbc7qFaTKw0w2kCoROEYhXmrqFDAgMBAAGjggH/MIIB+zASBgNV HRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjARBgNVHSAECjAIMAYGBFUdIAAwHQYD VR0OBBYEFLcrb8DHGBAxNhdSEHWh0EDDOTQfMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn3 8QpwPt5kMB0GA1UdEQQWMBSBEnBraUB1bmktbHVlYmVjay5kZTCBiAYDVR0fBIGAMH4wPaA7 oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNy bC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHVi L2NybC9jYWNybC5jcmwwgdcGCCsGAQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8v b2NzcC5wY2EuZGZuLmRlL09DU1AtU2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9j ZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcG CCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j YWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQsFAAOCAQEAdYeYj/1b9DL3QJ4OXOWkGJsv yq1Y5rUXkBp9gfrWv4hwHrojJAgzgSf6D9f4emRAl85q59g/MbcEa6ykxFaVqwDnf72vP8+y E7lRTf7fX5RwtX4OWdqSvdwL/yERRcXkC1OSZoLNgWbV3LgVx1qorSlRFf1g7GFGpRz6+We5 UpxrbRNLpCctu8nI3j+/Yf0gHemPd47+UsqJyqJSGR2PRwes2145sN3SKNIGwNuGD9yT31ME IGbQYs5+tvVwy4dPL563krryekiACiMIdlmAuq07gEY3cJcQpxRfQT7TGLE6A2BBHEOCI/bm qvxf3sleblFjqbX/4Q9fvBBV5Ri2iTCCBa8wggSXoAMCAQICBxjfNvsLscMwDQYJKoZIhvcN AQELBQAwezELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNr MScwJQYDVQQDEx5DQSBkZXIgVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0B CQEWEnBraUB1bmktbHVlYmVjay5kZTAeFw0xNTAxMjExNDM2MjdaFw0xODAxMjAxNDM2Mjda MGkxCzAJBgNVBAYTAkRFMSAwHgYDVQQKExdVbml2ZXJzaXRhZXQgenUgTHVlYmVjazEgMB4G A1UECxMXSW5zdGl0dXQgZnVlciBUZWxlbWF0aWsxFjAUBgNVBAMTDU9saXZlciBLbGVpbmUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA68ufre0edWEVwZPx2Ur3Haw0Jujt GnNI0fhuh9DVxEHmHENt3jr7KeczK5+eS/kxHx3OoiLuJSNPxuoJ2M14aWIrJPU5ZS6hfbxl CosqCJlvPyNb85lE18BaR7fSmCKpn6766WK/3/K13vF7lMlm+if+mNv1Fo45JIsBGSNkKCrM HOVESfmUVrdkkKXaKL24H7kouED9gPAyTqG23XvFxd3JWHLpq4aGA/NWnDpcyqOpovb3bIae CpObD16FlfcE7yL9BxNlRPxVQ6s+uhXjp9T5/5KC/yXITO4wmn8Mm1Ayrf586sESr98S5A+D bwGTaotKo08NZeuPsrhncELnAgMBAAGjggJIMIICRDBABgNVHSAEOTA3MBEGDysGAQQBga0h giwBAQQDAzARBg8rBgEEAYGtIYIsAgEEAwEwDwYNKwYBBAGBrSGCLAEBBDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYE FDi+RAwHFnUHTn3ye1QbirMevhyIMB8GA1UdIwQYMBaAFLcrb8DHGBAxNhdSEHWh0EDDOTQf MCQGA1UdEQQdMBuBGWtsZWluZUBpdG0udW5pLWx1ZWJlY2suZGUwgYgGA1UdHwSBgDB+MD2g O6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1 Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSByjCBxzAzBggrBgEFBQcwAYYnaHR0cDov L29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQMEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL3VuaS1sdWViZWNrLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBH BggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS91bmktbHVlYmVjay1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQELBQADggEBAH7rO2CNs9yHSBVdXZfH0FK4 W1Dsj5viQezzAaauKehV1SN1B/BSsTwgNfGR5VwFgeVxMEr3syTWPzSqLe2X938kLogfI87K 4fsgvNIN8kDXed2HjJZp5QKS/HL1OHKBIbYHVLB3aVvnUtf9RYXPeEV9GYxCZxIjmer6gvsV kSuPE66ZN84V4rt7kCfCMdsB+p2KTL33bTmBBbrTL9/JbG+gmFXV36YYAUGfEHKhNeSO2Kpx Pm0+0CyE+49yJ47kjOpMW+e1xCad+3r2SU3sGkZKcJ0CVsZnzDBQT/M4ZqtpQmzKLFht3Tgm O6+FEsLWh45Q53asSbX4Kiyv9IfF28kxggPDMIIDvwIBATCBhjB7MQswCQYDVQQGEwJERTEg MB4GA1UEChMXVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxJzAlBgNVBAMTHkNBIGRlciBVbml2 ZXJzaXRhZXQgenUgTHVlYmVjazEhMB8GCSqGSIb3DQEJARYScGtpQHVuaS1sdWViZWNrLmRl AgcY3zb7C7HDMA0GCWCGSAFlAwQCAQUAoIICDTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA0MjExNTM1MjZaMC8GCSqGSIb3DQEJBDEiBCAfaBcn31be 5pw7bweZTm/ZaNkIDlwZWhOy0cb51lQRsDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGXBgkrBgEEAYI3EAQxgYkwgYYwezELMAkG A1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMScwJQYDVQQDEx5D QSBkZXIgVW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmkt bHVlYmVjay5kZQIHGN82+wuxwzCBmQYLKoZIhvcNAQkQAgsxgYmggYYwezELMAkGA1UEBhMC REUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCB6dSBMdWViZWNrMScwJQYDVQQDEx5DQSBkZXIg VW5pdmVyc2l0YWV0IHp1IEx1ZWJlY2sxITAfBgkqhkiG9w0BCQEWEnBraUB1bmktbHVlYmVj ay5kZQIHGN82+wuxwzANBgkqhkiG9w0BAQEFAASCAQAXFGBpH8F/gdvRKs3KxP7aUx1Hi2m+ 94fH8FcGxgb7fi5if9ghxcgatx4sUdETvKNo0Bys6axLP7odSXG99kiAqMlG22jnZSqU8xh1 ZDgW7rAME1bSJmP3fteeFKzkicmlgWqeB8PVsy3MlO0Ur8L5OkLCQBg9g7GwbybuJpAgr6Uw M8P3VAKrqWPGpcf0jjB+PpvabmEv2N51EjYVc8tnjWeBFVNkkl8+FJVAhKNA2t1zlo/djx0X WNJQx3InjtieQIgU4bZHH14B/PYoCmt9Q6I7zk5tMVoIG5qMGuhcAK/WVynchIH9iVHowuTQ PZyGYXrOhbEPojCigAA68JkAAAAAAAAA --------------ms000704070908080508050500-- From nobody Thu Apr 21 09:00:03 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147B312D8A7 for ; Thu, 21 Apr 2016 08:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 BnwI3ZEFmRvs for ; Thu, 21 Apr 2016 08:59:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F40312E058 for ; Thu, 21 Apr 2016 08:59:51 -0700 (PDT) Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LwrwO-1bm0E125jE-016RzL; Thu, 21 Apr 2016 17:59:41 +0200 To: Carsten Bormann References: <56FC0673.2020707@gmx.net> <56FC23AB.1080007@tzi.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5718F8EA.5010006@gmx.net> Date: Thu, 21 Apr 2016 17:59:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FC23AB.1080007@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8v0Lri5FBasdqj1klf4PAITF3bAeBsUA5" X-Provags-ID: V03:K0:A25lRNtzVCZq+I2ecRUbFQ5pBIBiHQgSyyYRK1Co4TV3F23yAoZ GT0IHVJCwUPXUF2obVsIeR6/1UfACQOluP8O/8kx+R/RYukbsbUhhlh2eUqSL8pb/H/2MCG Yg1zhiZH8efZkjuP6TYKLDf2T+0CsJIvrcV+WTNtDi2Xc/jc97txhDqKvI3pbkkwhqQPOq9 fr/Peazgl3gcG8KxuiS7A== X-UI-Out-Filterresults: notjunk:1;V01:K0:qRiwFKbp+GY=:lSPfJtwyh2dLwECc0UOTM9 tYh6D/0F6Flt/dDqOwzOH7/M27cwPoNHepg+hG+XlTBoaaTt9TqtjfywGnc5A1BZ/1elB31mb K4piGRgdL/x40/1sNQBLB5GRGin4dgVybR7oihQNkVy7X50b4CYHAG+fwfkShfpmRucYlGCZO Acash/pTF+0aQZtrQeLlDVosGBxIdQ/5LkAnRxw1nRYRsw68Li6vICtVzhWii8pMvNpLsVI2L ZKWXCUWPUwoDiMxLiaGnwDItC9uyu8Bzh8BrLhoNVDV+ulkcEJuP9tGYYYg6B2mBQMvls3yCT M+sz73+ZHwBhyduranFRgXRoDPmLag6lwjDbullwXrVLWJ1WbonZKK0hpAiS96rLL2gUsmyGU 0za0er8AppFP7rox3FkddQN9iizhLb1BxIozbYgtwE2uztTs7RW+bd0GwLF78GCNbZfzmHTWW YkKqCD+QpqgudnPXCSqLspkd6stRbPO8lScnBQhNU0obQs9Atc/VYzkKWrBTp2pcByqzM+Vfx W0Mc9zXPvhMfEswhCuUGHkiWL75VZLwXGZOcKdtigQh+tgItf8E++uNsETPspTEtdLFO6P9E3 OZ7c6xfcO5R+DAmpmeK2rVd8KnSDq3EfvzyqKrjGlgnpXI6UjjXZfn4lJ/0mMF+OA4D3mhg7c /XmqIzFdwp4eOgB7dkLLP/SFjNkaR3cDE85bA91b9DeeO1/Ov9zcQyWu3MVHx112WdzQq1He1 lieBrPImZNsVTXzaeMSURfGO36/XjBA+29iFyIRftgEsGIhP6lRckTCvm9M= Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoAP over TCP: Extending the shim Header Payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 15:59:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8v0Lri5FBasdqj1klf4PAITF3bAeBsUA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, Hi all, I am trying to follow-up on this topic. =46rom the discussion at the last IETF meeting I believe we agreed that w= e want to explore the concepts described below. Is that true? I have re-read your write-up below and my earlier understanding was that we have to add another short shim header field to distinguish a CoAP packet from something else. You seem to have a different view about this, if I interpret it correctly. Re-using CoAP sounds like a good idea but also means that we are overloading the semantic of CoAP payloads an messages. Do we want that? Just selecting two of the features Klaus has raised. 1) Error Handling: Server returns a message that it was unable to process the message (for example, due to an incorrect message length) Client Server | | | <--- TCP ---> | | Connection Setup | | | | NON | | GET /temperature | | (Token 0x74) | +----------------->| | | | NON | | 4.00 Code | | (Token 0x74) | |<-----------------+ | | | <--- TCP ---> | | Conn. Teadown | Here the question is how we can indicate that the error message actually does not refer to the initial CoAP request but rather indicates the inability of the server to process the request at all. It just happens to provide the response in a CoAP-based format. I picked an error code from the available range that feels appropriate. 2) Server Name Indication: Client provides the SNI (i.e., a HostName) to the server. Client Server | | | <--- TCP ---> | | Connection Setup | | | | NON | | GET /temperature | | (Token 0x74) | |+ SNI: example.com| +----------------->| | | | NON [0x23bc] | | 2.05 Content | | (Token 0x74) | | "22.5 C" | |<-----------------+ | | | ...... | | time passes | | ...... | | | | <--- TCP ---> | | Conn. Teadown | How does this approach look like? Ciao Hannes On 03/30/2016 09:06 PM, Carsten Bormann wrote: > I didn't write this up yet, but it seems I'll have to. >=20 > Any extension to the shim header will soon grow into a protocol that is= > as complex as CoAP itself. >=20 > Instead, we should simply re-use a protocol that we already have: CoAP.= >=20 > (If we really need to do all of this; I'm not convinced yet.) >=20 > See below for how (I haven't checked the details against your new > protocol, but it's the gist I'm after here). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > # Signaling messages >=20 > Signaling messages are structured like any other CoAP message; they > have a code, a token, options, and optionally a payload. > The code for a signaling message comes from the 7.xx space. >=20 > Option numbers for signaling messages are specific to the message > code, i.e., they do not share the number space with CoAP options for > request/response messages or with signaling messages using other > codes. > Signaling options can be elective or critical; if a signaling message > option is critical and not understood by the receiver, it MUST abort > the connection. (If the option is understood but somehow cannot be > carried out, the option defines how to handle the error.) >=20 > Payloads in signaling messages are diagnostic payloads, unless > otherwise determined by a signaling message option. >=20 > Five types of signaling messages are defined: >=20 > * Capability messages: indicate a capability to the peer. Most > capability options will be elective. Capability indications are > cumulative, i.e., a capability message without any option is a > no-operation (and can be used as such). (An option that is given > might override a previous value for the same option; the option > defines how to handle this, if needed.) Most options are defined > only for the first message in the connection. >=20 > * Ping, pong: A ping message is responded to by a pong message with > the same token. No options are defined for Ping messages in this > specification, but options might be defined later. As with all > signaling messages, the receiver of a ping or pong message MUST > ignore elective options it does not understand. >=20 > * Release. A release message indicates that the sender does not want > to continue maintaining the connection and opts for an orderly > shutdown; the details are in the options. A release message will > normally be replied to by a release message as soon as possible by > the receiver; only then is the connection closed. (To do: define > who actually closes the TCP connection.) >=20 > * Abort. An abort message indicates that the sender is unable to > continue maintaining the connection and cannot even wait for an > orderly release; the sender shuts down the connection immediately > after the abort (and may or may not wait for a release or abort > message in the inverse direction). >=20 > Release and abort messages indicate one or more reasons using elective > options. >=20 > ## Discussion >=20 > Capability messages remove the perceived need for versioning. > (Versioning is great for keeping incompatible implementations from > accidentally trying to talk to each other, but is not a good > evolution strategy.) >=20 > An effect similar to the ping/pong message can be achieved by creating > a resource that has appropriate no-operations semantics (e.g., returns > an empty payload on a GET or returns the payload given on a POST). > Handling the function as a signaling message keeps the resource name sp= ace > clean of such resources. >=20 > The need for orderly release only becomes apparent in the presence of > non-idempotent requests such as POST. > It does not solve the problem that a connection that breaks in an > uncontrolled way keeps the status of that request unclear. >=20 --8v0Lri5FBasdqj1klf4PAITF3bAeBsUA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXGPjrAAoJEGhJURNOOiAtpUAH/0+7UFybM6ovxWOH4ykxqAwp nGG6qfqVlO4ti5QxafdLYsd+6/BTyq1JF50MyJa6vWFnEPaHvViTjfqQatpAhO6m BMKnf4bIUOLNywhwxy+uSZTiaSnjDE659XRl8lYRkuEBNHcPfKAv2AjhHKrlC0mN HatGI0MwBbiq4JwlE3A25SUGdPVC6Ijdj8f0esOqSAXyB2FnqqEK2985DUQJ2cN5 yfj7qqtxgOAG1QNscs2scd+ZVxs1yeBiAMOPilPxioweBxCC22kXc+yLlN6WreNK 8JzS28MZ1/tB3F6buO6Tz/VMkC9bLrPgKUxEJw9+0RNxKYk5to1lzKOagIHyCF8= =Qs4z -----END PGP SIGNATURE----- --8v0Lri5FBasdqj1klf4PAITF3bAeBsUA5-- From nobody Thu Apr 21 09:12:28 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7D812E769 for ; Thu, 21 Apr 2016 09:12:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_Dx68yYas_G for ; Thu, 21 Apr 2016 09:12:23 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F72E12E5D7 for ; Thu, 21 Apr 2016 09:12:22 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id g184so63720940lfb.3 for ; Thu, 21 Apr 2016 09:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xXDSrm3BPQdhuPjPunNB3WAcoIr7qEGDnT7DoCDxR40=; b=tLPL3BqHCbJ9UTEGJTg+UFQ9bX8I6q0hgp4gHRxDqccSQlUJ4u2ypTRFvq3sgFB4YU yHEzqSIw1MYdBjpdnWFZuNZqeRF4n01Iz/DLnUtlxJpd9LiVBj37LFrz3c8fjgNZJ20/ LKkqn0xmD49RB1vJCxjf1Ky7b5aVOfzWSMabwrlUAmD7vJrTIJUzyUyKEh7sjjYUtuxs nsijAKWDDEBQrbs16BOQDSwrvYXKsA/eljDxoxd0b+NZqUEu5IjTLb2FbeOJ3n/aPyXT i4HfHRaHvGN6g3Te7r7RHxRrU59sgRbzW03aMFO6I8yzXSydy9u+LIN49sIjgz8TsYpp k5qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xXDSrm3BPQdhuPjPunNB3WAcoIr7qEGDnT7DoCDxR40=; b=GwVugw5WeCFYx8bynWXWCO1pZiyxphI4LbuQpDKOcPsIfvKoCT1Ml3LS4oQbLSZx1a +NDt/1ZnH5N6R9+upJN6AMluZRpSatLcARDP1bwKovs00vWPenzYb8VXl9xbyFgoqVap j70KFhMxv+Wx+ZvU94rGIughlZbDPUFQi559mxiOrw3MBp7Iaum75YQlXoz14WvrRhAm SOQXQhfeZIi+sPByoKRLxaHd69GNMICbrPqrdKlN5Th6ynK1bFHFO2X+sqWMGZRjAKCc 1ja4xgP0cKCq00c7IU4Wozj7XZ/iQhdImfidcZ5dcBZ3rPjCsekw+5o0qezpefHzmm7W rJxA== X-Gm-Message-State: AOPr4FVmD7vG6rP42SZpDHftny0tSAuv5ASNcwo4LjDn6PkerGFpHa73QD7dqvI4HpCgF9CnFBru2K0vqc4BVA== MIME-Version: 1.0 X-Received: by 10.25.27.200 with SMTP id b191mr7104564lfb.8.1461255140748; Thu, 21 Apr 2016 09:12:20 -0700 (PDT) Received: by 10.112.198.70 with HTTP; Thu, 21 Apr 2016 09:12:20 -0700 (PDT) In-Reply-To: <5718A09E.7040607@gmx.net> References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> Date: Thu, 21 Apr 2016 09:12:20 -0700 Message-ID: From: Andy Bierman To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11402c48974b2f053100f97a Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:12:26 -0000 --001a11402c48974b2f053100f97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am obviously a proponent of using YANG, for the reasons outlined in our IOTSI position paper: https://www.iab.org/wp-content/IAB-uploads/2016/03/CoMI_IoT_Position_Paper_= 4.pdf You are asking the right questions -- is it worth the effort to use a formal data modeling language in IoT? If the data models are trivial, why bother? IMO, here's why: - the model is a formal description of the server API. Client programmers need to code to your server API. Mistakes like 1 side thinks it's meter= s and the other side thinks it's feet can be catastrophic. Automated data validation can help avoid that. - the model fully describes the API so there is no need to send any meta-data with API content. This saves a lot of bandwidth. The client reads the module-set ID and the YANG module list (once) if the module-set ID is unknown. - the model can define defaults. The protocol can utilize this info to omit lots of data on the wire without any loss of info. - unconstrained devices on constrained networks need real data models - the lack of IoT YANG modules is a reflection on the lack of a protocol suitable for constrained devices. NETCONF is focused on SDN and there is no concern whatsoever for CPU, memory, or network usage. - YANG is functioning as an easy-to-use info modeling language, because there are multiple protocols and multiple message encoding formats supporting it. YANG to CBOR will provide an efficient encoding format that could be used in many protocols, not just CoAP. Andy On Thu, Apr 21, 2016 at 2:42 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Carsten, Hi all, > > I think we are going to fast here. > > We hardly make any progress with the existing WG items but then we add a > number of new items that are barely understood. > > This call for adoption is not a call for this document this is a > question whether we want to work on the following two types of things: > > a) a data modelling language (Yang) for use with IoT objects (which in > case of IoT are largely defined elsewhere), and > > b) re-use a protocol machinery originally defined for network management > around Netconf (which may now be converted to CoAP and CBOR usage). > > I have spent some time trying to figure out what the implications are > and (that's a bold statement) doubt that most WG participants (except > for the authors of the documents) really understand what this really mean= s. > > Here are the claims: > > 1) IoT will re-use many of the objects defined for network management. > > 2) There is a need for a formal language to describe the data model. > > 3) There is a value in generating code using that formal data model > description. > > 4) Yang (as a data modelling language) and the related protocols are a > good match for the requirements people have. > > Are these claims actually true? > > Given that we are late at the party and other organizations have done a > fair amount of work in that space already I am wondering whether we have > done our home work of analysis the existing landscape or whether we are > just interested to add another set of standards to the mix. > > I have my opinion about the claims and I would like to share them with yo= u. > > Regarding (1) on the re-use argument. I do not believe that the > existing, already standardized objects defined for network management > are a good fit for what we are doing in IoT. I have not seen the > examples where there is re-use. As illustrated below, I am exposing my > sensors, buttons, and LEDs to outside world rather than network > interfaces and alike. I fully understand that the world is far more > complex with routers and switches that have many ports and lots of > configuration parameters. They are also running regular operating > systems, like Linux. > > Regarding (2) on the use of formal languages. It seems that most > organizations are using formal languages for describing their object > definitions already today. I personally believe that these formal > languages do not provide a lot of value in general but using something > that is easy for humans to write and read is something I may be OK with. > Particularly the example below shows that all I need as a developer is > very little. IoT devices typically do not have many sensors and the > implementation complexity is elsewhere (with the operating system, the > tool chain, and various low power settings). > > Regarding (3) on the value of code generation. > > I am currently in the process of writing a new tutorial for a developer > workshop hosted by the Open Mobile Alliance (OMA), see > > http://openmobilealliance.org/free-hands-on-training-for-iot-developers-w= ith-oma-lwm2m-and-arm-based-microprocessors/ > > I am using regular IoT hardware, namely the K64F board with onboard > sensors, namely an accelerometer and magnetometer, an RGB LED, and two > buttons. The sensors are connected using I2C and are certainly not among > the most simplistic (which the data sheet of almost 100 pages can easily > tell you). > > In the process of writing code I need to do the following: > > * Figure out how to connect to the sensors using I2C. > > * Learn how the sensor works, how to configure the sensor to do what I > want, and to convert the raw sensor data into something suitable for my > application. One can only hope to find a library that does these things > already and to only have to adjust the settings rather than writing > everything from scratch. That typically takes a lot of time. > > * Determine whether is a suitable object definition already available. > In my case I am looking at the OMNA registry (which has also been > populated with the objects from the IPSO Alliance). Here are the > registered objects: > > http://technical.openmobilealliance.org/Technical/technical-information/o= mna/lightweight-m2m-lwm2m-object-registry > > In case of the Accelerometer and the Magnetometer I am lucky since those > have already been defined. I don't need to define my own objects, which > is a simple task given the new OMA object editor > http://devtoolkit.openmobilealliance.org/OEditor/Default > > * Then, I need to add the code for use with them. Here is where the > formal description of the data model could help me to automatically > produce code. > > Now, this is the funny thing: this code amounts for around 5 lines, > depending on the API and programming language you are using. Most likely > the code generation will produce some code that you cannot directly use. > > Here is what I have to write on the IoT side: > > ---- > > // Create object '3313' =3D 'Accelerometer' > acc_object =3D M2MInterfaceFactory::create_object("3313"); > > M2MObjectInstance* acc_inst =3D acc_object->create_object_instance(); > > M2MResource* acc_x_res =3D acc_inst->create_dynamic_resource("5702", "X > Value",M2MResourceInstance::FLOAT, true /* observable */); > > M2MResource* acc_y_res =3D acc_inst->create_dynamic_resource("5703", "Y > Value",M2MResourceInstance::FLOAT, true /* observable */); > > M2MResource* acc_z_res =3D acc_inst->create_dynamic_resource("5704", "Z > Value",M2MResourceInstance::FLOAT, true /* observable */); > > ----- > > I fear that we are optimizing for something that does not take a long > time anyway. It will take longer to fetch the relevant Yang file, to use > the tools to generate the code and to integrate it into the existing > code than to just write these few lines yourself. > > What the above example does not utilize potential code generation for > the actual interaction model. In my case my code is hard-wired to use > LWM2M. > > Since I have not yet seen a meaningful example of Yang for the IoT > environment I also haven't seen one that produces meaningful code for > the interaction model either. > > Regarding (4) concerning Yang as a data modelling language (vs. other > languages also considered by the IoT communities). As Paul noted there > are other languages in town and I personally do not know whether the > features offered by Yang are better or equal to those offered by the > other languages. I certainly haven't done that analysis. > > As a concluding remark I would like to say that while my current > assessment may sound negative I am happy to learn more about this topic > and might get convinced that Yang is the right tool. Currently, I just > haven't reached that level yet and I can claim that I have spent some > time looking at this topic already. > > Ciao > Hannes > > > On 04/10/2016 02:22 PM, Carsten Bormann wrote: > > In Buenos Aires, we discussed the adoption of > > draft-veillette-core-yang-cbor-mapping-00 but not enough people had rea= d > > the document to go for an in-room consensus call. > > > > This is a two-week call for adoption of > > draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. > > Specifically, if you (1) support or (2) have an objection to this > > decision, please speak up on the mailing list by 2016-04-24. > > > > Note that this work is explicitly covered by our charter, so discussion= s > > of which WG should work on this are off-topic. > > > > As always, adoption of a document as a WG document is not a vote on > > whether we already have reached last-call state; the intention is to > > work on the WG document after adoption for a while to get it ready for > > last call. If you want to combine your support/objection with technica= l > > comments, this is certainly welcome so we can accelerate that process. > > > > 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 > > --001a11402c48974b2f053100f97a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am obviously a proponent of using= YANG, for the reasons outlined
in our IOTSI position paper:


Y= ou are asking the right questions -- is it worth the effort to
us= e a formal data modeling language in IoT?=C2=A0 If the data models
are trivial, why bother?

IMO, here's why:

=C2=A0- the model is a formal description of the ser= ver API. Client programmers
=C2=A0 =C2=A0need to code to your ser= ver API.=C2=A0 Mistakes like 1 side thinks it's meters
=C2=A0= =C2=A0and the other side thinks it's feet can be catastrophic.=C2=A0 A= utomated
=C2=A0 =C2=A0data validation can help avoid that.
<= div>
- the model fully describes the API so there is no need = to send any meta-data
=C2=A0 with API content.=C2=A0 This saves a= lot of bandwidth.=C2=A0 The client reads the
=C2=A0 module-set I= D and the YANG module list (once) if the module-set ID is unknown.

- the model can define defaults. The protocol can utilize = this info to omit lots
=C2=A0 of data on the wire without any los= s of info.

=C2=A0- unconstrained devices on constr= ained networks need real data models

=C2=A0- the l= ack of IoT YANG modules is a reflection on the lack of a protocol
=C2=A0 =C2=A0suitable for constrained devices.=C2=A0 NETCONF is focused on= SDN and there
=C2=A0 =C2=A0is no concern whatsoever for CPU, mem= ory, or network usage.

=C2=A0- YANG is functioning= as an easy-to-use info modeling language, because
=C2=A0 =C2=A0t= here are multiple protocols and multiple message encoding formats
=C2=A0 =C2=A0supporting it.=C2=A0 YANG to CBOR will provide an efficient e= ncoding format
=C2=A0 =C2=A0that could be used in many protocols,= not just CoAP.


Andy

On Thu, Apr 21, 2016 at 2:42 AM, Hannes Tschofenig <<= a href=3D"mailto:hannes.tschofenig@gmx.net" target=3D"_blank">hannes.tschof= enig@gmx.net> wrote:
Hi Carsten, Hi all,<= br>
I think we are going to fast here.

We hardly make any progress with the existing WG items but then we add a number of new items that are barely understood.

This call for adoption is not a call for this document this is a
question whether we want to work on the following two types of things:

a) a data modelling language (Yang) for use with IoT objects (which in
case of IoT are largely defined elsewhere), and

b) re-use a protocol machinery originally defined for network management around Netconf (which may now be converted to CoAP and CBOR usage).

I have spent some time trying to figure out what the implications are
and (that's a bold statement) doubt that most WG participants (except for the authors of the documents) really understand what this really means.=

Here are the claims:

1) IoT will re-use many of the objects defined for network management.

2) There is a need for a formal language to describe the data model.

3) There is a value in generating code using that formal data model
description.

4) Yang (as a data modelling language) and the related protocols are a
good match for the requirements people have.

Are these claims actually true?

Given that we are late at the party and other organizations have done a
fair amount of work in that space already I am wondering whether we have done our home work of analysis the existing landscape or whether we are
just interested to add another set of standards to the mix.

I have my opinion about the claims and I would like to share them with you.=

Regarding (1) on the re-use argument. I do not believe that the
existing, already standardized objects defined for network management
are a good fit for what we are doing in IoT. I have not seen the
examples where there is re-use. As illustrated below, I am exposing my
sensors, buttons, and LEDs to outside world rather than network
interfaces and alike. I fully understand that the world is far more
complex with routers and switches that have many ports and lots of
configuration parameters. They are also running regular operating
systems, like Linux.

Regarding (2) on the use of formal languages. It seems that most
organizations are using formal languages for describing their object
definitions already today. I personally believe that these formal
languages do not provide a lot of value in general but using something
that is easy for humans to write and read is something I may be OK with. Particularly the example below shows that all I need as a developer is
very little. IoT devices typically do not have many sensors and the
implementation complexity is elsewhere (with the operating system, the
tool chain, and various low power settings).

Regarding (3) on the value of code generation.

I am currently in the process of writing a new tutorial for a developer
workshop hosted by the Open Mobile Alliance (OMA), see
http://openmobilealliance.org/free-hands-on-training-for-i= ot-developers-with-oma-lwm2m-and-arm-based-microprocessors/

I am using regular IoT hardware, namely the K64F board with onboard
sensors, namely an accelerometer and magnetometer, an RGB LED, and two
buttons. The sensors are connected using I2C and are certainly not among the most simplistic (which the data sheet of almost 100 pages can easily tell you).

In the process of writing code I need to do the following:

* Figure out how to connect to the sensors using I2C.

* Learn how the sensor works, how to configure the sensor to do what I
want, and to convert the raw sensor data into something suitable for my
application. One can only hope to find a library that does these things
already and to only have to adjust the settings rather than writing
everything from scratch. That typically takes a lot of time.

* Determine whether is a suitable object definition already available.
In my case I am looking at the OMNA registry (which has also been
populated with the objects from the IPSO Alliance). Here are the
registered objects:
http://technical.openmobilealliance.org/Technical/technical-i= nformation/omna/lightweight-m2m-lwm2m-object-registry

In case of the Accelerometer and the Magnetometer I am lucky since those have already been defined. I don't need to define my own objects, which=
is a simple task given the new OMA object editor
http://devtoolkit.openmobilealliance.org/OEd= itor/Default

* Then, I need to add the code for use with them. Here is where the
formal description of the data model could help me to automatically
produce code.

Now, this is the funny thing: this code amounts for around 5 lines,
depending on the API and programming language you are using. Most likely the code generation will produce some code that you cannot directly use.
Here is what I have to write on the IoT side:

----

// Create object '3313' =3D 'Accelerometer'
acc_object =3D M2MInterfaceFactory::create_object("3313");

M2MObjectInstance* acc_inst =3D acc_object->create_object_instance();
M2MResource* acc_x_res =3D acc_inst->create_dynamic_resource("5702&= quot;, "X
Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_y_res =3D acc_inst->create_dynamic_resource("5703&= quot;, "Y
Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_z_res =3D acc_inst->create_dynamic_resource("5704&= quot;, "Z
Value",M2MResourceInstance::FLOAT, true /* observable */);

-----

I fear that we are optimizing for something that does not take a long
time anyway. It will take longer to fetch the relevant Yang file, to use the tools to generate the code and to integrate it into the existing
code than to just write these few lines yourself.

What the above example does not utilize potential code generation for
the actual interaction model. In my case my code is hard-wired to use
LWM2M.

Since I have not yet seen a meaningful example of Yang for the IoT
environment I also haven't seen one that produces meaningful code for the interaction model either.

Regarding (4) concerning Yang as a data modelling language (vs. other
languages also considered by the IoT communities). As Paul noted there
are other languages in town and I personally do not know whether the
features offered by Yang are better or equal to those offered by the
other languages. I certainly haven't done that analysis.

As a concluding remark I would like to say that while my current
assessment may sound negative I am happy to learn more about this topic
and might get convinced that Yang is the right tool. Currently, I just
haven't reached that level yet and I can claim that I have spent some time looking at this topic already.

Ciao
Hannes


On 04/10/2016 02:22 PM, Carsten Bormann wrote:
> In Buenos Aires, we discussed the adoption of
> draft-veillette-core-yang-cbor-mapping-00 but not enough people had re= ad
> the document to go for an in-room consensus call.
>
> This is a two-week call for adoption of
> draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. > Specifically, if you (1) support or (2) have an objection to this
> decision, please speak up on the mailing list by 2016-04-24.
>
> Note that this work is explicitly covered by our charter, so discussio= ns
> of which WG should work on this are off-topic.
>
> As always, adoption of a document as a WG document is not a vote on > whether we already have reached last-call state; the intention is to > work on the WG document after adoption for a while to get it ready for=
> last call.=C2=A0 If you want to combine your support/objection with te= chnical
> comments, this is certainly welcome so we can accelerate that process.=
>
> 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


--001a11402c48974b2f053100f97a-- From nobody Thu Apr 21 09:23:49 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8B12D7AB for ; Thu, 21 Apr 2016 09:23:47 -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] 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 dzZTHRENsjcV for ; Thu, 21 Apr 2016 09:23:46 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEC412D70A for ; Thu, 21 Apr 2016 09:23:45 -0700 (PDT) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 80F9EA80E6; Thu, 21 Apr 2016 18:23:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id SK4DvvWlyGqe; Thu, 21 Apr 2016 18:23:42 +0200 (CEST) X-Originating-IP: 93.199.242.26 Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B7CE2A80DC; Thu, 21 Apr 2016 18:23:41 +0200 (CEST) Message-ID: <5718FE8B.7010904@tzi.org> Date: Thu, 21 Apr 2016 18:23:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Hannes Tschofenig References: <56FC0673.2020707@gmx.net> <56FC23AB.1080007@tzi.org> <5718F8EA.5010006@gmx.net> In-Reply-To: <5718F8EA.5010006@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] CoAP over TCP: Extending the shim Header Payload X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 16:23:48 -0000 > From the discussion at the last IETF meeting I believe we agreed that we > want to explore the concepts described below. Is that true? I think so. With an emphasis on "explore" -- we don't have to do everything that comes to mind. > I have re-read your write-up below and my earlier understanding was that > we have to add another short shim header field to distinguish a CoAP > packet from something else. You seem to have a different view about > this, if I interpret it correctly. Right, there is no need to bloat up the header again because we can use the code field for that. > Re-using CoAP sounds like a good idea but also means that we are > overloading the semantic of CoAP payloads an messages. Do we want that? There is no overloading, as signaling messages are clearly distinct from request/response messages. They just share the same encoding, so we have less invention and less implementation work. > How does this approach look like? Well, we define signaling messages for settings and error messages. Note there is very little point in elaborate handling of encoding errors (such as incorrect message lengths), these are just there for debugging and can therefore be the diagnostic payloads of an otherwise very simple signaling message (section 5.5.2 of RFC 7252). More interesting is an indication of the reason for orderly release (e.g., a node might want to know whether the other node is OK with re-establishing the connection now or later), here we probably want to define different messages and/or options/option values to enable programmatic handling of these cases. Do we have an idea of what settings we want to provide? These could be 1) capability indications (probably the majority of the cases), e.g.: a) can handle messages larger than 1152 bytes (and how large) b) can do BERT ... 2) actual settings, such as SNI or default Uri-Host. Grüße, Carsten From nobody Thu Apr 21 10:35:02 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A012E1CC for ; Thu, 21 Apr 2016 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSKhTBq1eZd0 for ; Thu, 21 Apr 2016 10:34:53 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4FB12E079 for ; Thu, 21 Apr 2016 10:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A/bADmrrUHQyMm2o0oYr9rRV+yy21lBLYs4bNZ9mpa4=; b=seNRq1+oNg92wTyP6e4LpeMJ5DDYCJL4PiKVd5WUVL1GO6T/HSX9l1IVO0iruVt8BCockY/Csf7I8Jd6FcTZ2K7R2CHdHl9udVOVIAerdbocUelei2PwYNuxGYjeDVVnX8SK6a3YHLkwnMtBlCBxYl8TDpB3IDnj1U9DVgjfPpk= Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 17:34:51 +0000 Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 17:34:51 +0000 From: Michel Veillette To: Hannes Tschofenig Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?= Thread-Index: AQHRkyOt8k0bOhfeX0GvA3ed8jYnhJ+UPhMAgAB4yuA= Date: Thu, 21 Apr 2016 17:34:50 +0000 Message-ID: References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> In-Reply-To: <5718A09E.7040607@gmx.net> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 05a605ee-81fe-4fc7-e5ff-08d36a0b3e67 x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:jglDGdSw3qxlZ5ANs6ojnAjA2smLZh/Xa16wa49bM4Z1XfpOcnav24aYhSUMAO0Y/AOdfA7GMIAOskZXQlo82PuvrRyZeK18dsFYT4HlHpqa2li2OwsuuDJK81e2t70OpVtbBI+k3j4yGsNIoq5itoABjv88IO/PEFTJ8jqH9RVdbORaAJiY272uxateOwnq; 24:xRPBfkxZlkqnl14KA5uDKtwgV7itmafjJXY+YdUGZnJTCtfY7vhPW838hhIlqeFoygchhtksl8wlk/apHN0uhKYRjY1e6SF7XHHuGBvUs/c=; 7:qv7gcYEB+t8UvhYtr0U4aIYtPEOSY5l0AgqwRzcO3SenLr/ObVN6z5veC7tbpKBj3a93GeYy4rYP4GsHWbta0qygLwCwdQfDmK8rgVWQcFE0y4o99OhzfL1CIRtpv2wBfdkV6i6IBX0jy4g7LsdWa8oN0AilQ6ksgYnlQAAWzUUjCd3/wH3vX5JzKyibZ04e5DyYEKbRlWsEGZKWGLJ5sjMNKOsVqznJNBIr2Z5RZm8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(24454002)(13464003)(15975445007)(1720100001)(2900100001)(5002640100001)(122556002)(586003)(1220700001)(1096002)(2950100001)(66066001)(77096005)(189998001)(6116002)(102836003)(3846002)(5003600100002)(92566002)(5008740100001)(10400500002)(74316001)(5004730100002)(15395725005)(106116001)(87936001)(3660700001)(99286002)(81166005)(3280700002)(19580405001)(19580395003)(86362001)(551934003)(33656002)(9686002)(76576001)(19625735002)(76176999)(54356999)(2906002)(50986999)(11100500001)(4326007)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 17:34:50.9959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:34:59 -0000 SGkgSGFubmVzDQoNCiMjIyBBcHBsaWNhdGlvbiB2cy4gTmV0d29yayBtYW5hZ2VtZW50DQoNCllv dXIgZW1haWwgc2VlbSB0byBkZXNjcmliZSBtYWlubHkgYW4gYXBwbGljYXRpb24gcHJvdG9jb2wg aW5zdGVhZCBvZiBhbiBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wuDQpUaGUgcmVxdWlyZW1l bnRzIG9mIGJvdGggYXJlIGRpZmZlcmVudCwgY2FwYWJpbGl0aWVzIGFyZSBvZnRlbiBkaWZmZXJl bnQgYW5kIGluIG1hbnkgY2FzZSwgYm90aCBhcmUgaW1wbGVtZW50ZWQgYnkgdGhlIHNhbWUgZGV2 aWNlLg0KDQpBIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbCBuZWVkIHRvIHN1cHBvcnQgdXNl IGNhc2VzIHN1Y2ggYXM6DQotIENvbW1pc3Npb25pbmcgLyBQcm92aXNpb25pbmcgb2YgYSBkZXZp Y2Ugd2l0aCBhIHdlbGwga25vd24gY29uZmlndXJhdGlvbiAoSW5pdGlhbGl6YXRpb24gb2YgYWxs IHJlc291cmNlcykNCi0gQXRvbWljIHRyYW5zYWN0aW9uIChUbyBhdm9pZCB0byBsZWF2ZSBhIG5v ZGUgaW4gYW4gaW5jb25zaXN0ZW50IHN0YXRlKQ0KLSBTY2hlZHVsZWQgLyBzeW5jaHJvbml6ZWQg Y29tbWl0IChUbyBhdm9pZCB0byBsZWF2ZSB0aGUgbmV0d29yayBpbiBhbiBpbmNvbnNpc3RlbnQg c3RhdGUpDQotIENvbmZpZ3VyYXRpb24gYmFja3VwIGFuZCByZXN0b3JlDQotIENvbmZpZ3VyYXRp b24gcm9sbGJhY2sgKFRvIHJlY292ZXIgZnJvbSBhIG1pc2NvbmZpZ3VyYXRpb24pDQotIEV2ZW50 IHN0cmVhbQ0KLSBEaWFnbm9zdGljIGFuZCBtb25pdG9yaW5nDQoNCiMjIyBNb2RlbGluZyBsYW5n dWFnZSB2cy4gY29kZSBnZW5lcmF0aW9uDQoNCllvdSBzZWVtIHRvIGltcGx5IHRoYXQgdGhlIHVz ZSBvZiBhIG1vZGVsaW5nIGxhbmd1YWdlIGlzIGRpcmVjdGx5IGFzc29jaWF0ZWQgd2l0aCBjb2Rl IGdlbmVyYXRpb24uDQpGaXJzdCwgTFdNMk0gaGF2ZSBpdHMgb3duIG1vZGVsaW5nIGxhbmd1YWdl IGVuY29kZWQgaW4geG1sLg0KQSBmaWxlIGxpa2UgIk9NQS1TVVAtWE1MX0xXTTJNX1NlY3VyaXR5 LVYxXzAtMjAxMzEyMTAtQyIgaXMgbm90IGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50IHRoYW4gc29t ZXRoaW5nIHRoYW4gY2FuIGJlIG5hbWVkIHNlY3VyaXR5LnlhbmcuDQpBIHNpbXBsZSB4bWwgdHJh bnNmb3JtIGNhbiBwcm9iYWJseSBkbyB0aGUgY29udmVyc2lvbiBiZXR3ZWVuIHRoZSB0d28gd2l0 aG91dCBhbnkgbG9zdC4NCkxXTTJNIGp1c3QgaGF2ZSBhIHNpbXBsZXIgKHN1YnNldCkgbW9kZWxp bmcgbGFuZ3VhZ2UuDQoNClRoZSBzYW1lIHdheSBhcyBMV00yTSwgYSBDb01JL0NvT0wgaW1wbGVt ZW50YXRpb24gZG9u4oCZdCBuZWVkIHRvIHJlbHkgb24gY29kZSBnZW5lcmF0aW9uLg0KVGhlIGZh Y3QgdGhhdCBDQk9SIGFsbG93cyBhIHNjaGVtYSBsZXNzIG9wZXJhdGlvbiBlbmFibGUgdGhlIGNy ZWF0aW9uIG9mIGEgY2xpZW50IG9yIHNlcnZlciBsaWJyYXJ5IHdoaWNoIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBvYmplY3QocykgaW1wbGVtZW50ZWQgYW5kIGNhbiBiZSB1c2VkIHdpdGggYW55IFlB TkcgbW9kdWxlLiBUaGlzIGlzIGluIGZhY3QgdGhlIGFwcHJvYWNoIHdlIGFyZSB0YWtpbmcgaW4g YW4gb3BlbiBzb3VyY2UgcHJvamVjdCB3ZSBhcmUgYWJvdXQgdG8gc3RhcnQuDQoNCiMjIyBFeGlz dGluZyB1c2VmdWwgc21pIC8geWFuZyBtb2R1bGVzDQoNClRoaXMgaXMgYSBsaXN0IG9mIHVzZWZ1 bCwgYWxyZWFkeSBleGlzdGluZyB5YW5nIG1vZHVsZXM6DQotIGlhbmEtaWYtdHlwZSAoaHR0cDov L3d3dy5uZXRjb25mY2VudHJhbC5vcmcvbW9kdWxlcy9pYW5hLWlmLXR5cGUvMjAxNC0wNS0wOCkN Ci0gaWV0Zi1pbmV0LXR5cGVzIChodHRwOi8vd3d3Lm5ldGNvbmZjZW50cmFsLm9yZy9tb2R1bGVz L2lldGYtaW5ldC10eXBlcy8yMDEzLTA3LTE1KQ0KLSBpZXRmLWludGVyZmFjZXMgKGh0dHA6Ly93 d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXMvaWV0Zi1pbnRlcmZhY2VzLzIwMTQtMDUtMDgp DQotIGlldGYtaXAgKGh0dHA6Ly93d3cubmV0Y29uZmNlbnRyYWwub3JnL21vZHVsZXMvaWV0Zi1p cC8yMDE0LTA2LTE2KQ0KLSBpZXRmLXlhbmctbGlicmFyeSAoaHR0cDovL3d3dy5uZXRjb25mY2Vu dHJhbC5vcmcvbW9kdWxlcy9pZXRmLXlhbmctbGlicmFyeS8yMDE0LTA5LTI2KQ0KLSBpZXRmLXN5 c3RlbSAoaHR0cDovL3d3dy5uZXRjb25mY2VudHJhbC5vcmcvbW9kdWxlcy9pZXRmLXN5c3RlbS8y MDE0LTA4LTA2KQ0KLSB5YW5nLW1wbCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXZhbmRlcnN0b2stY29yZS1tcGwteWFuZy0wMCkNCi0gcnBsTWliIChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2VoZ2FsLXJvbGwtcnBsLW1pYi0wNikNCi0gbG93cGFuTUlCICho dHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXNjaG9lbnctNmxvd3Bhbi1taWIt MDMudHh0KQ0KDQpIb3dldmVyLCB0aGUgbWFpbiBhZHZhbnRhZ2Ugb2YgdXNpbmcgWUFORyBpcyBu b3QgbmVjZXNzYXJ5IGluIHRoZSBsaXN0IG9mIGFscmVhZHkgZXhpc3RpbmcgbW9kdWxlcyBidXQg aW4gWUFORyBpdHNlbGYgYW5kIHRoZSB0aWdodCBpbnRlZ3JhdGlvbiB3aXRoIHRoZSByZXN0IG9m IG5ldHdvcmsgbWFuYWdlbWVudCB3b3JsZCBtb3ZpbmcgZm9yd2FyZC4NCg0KSWYgeW91IGhhdmUg YW55IG1vcmUgcXVlc3Rpb25zLCBkb24ndCBoZXNpdGF0ZSB0byBhc2suDQpXZSB3aWxsIGNlcnRh aW5seSB0YWxrIGFnYWluIGFib3V0IGl0IGFyb3VuZCBhIGJlZXIgaW4gQmVybGluIDspDQoNClJl Z2FyZHMsDQoNCkhhbm5lcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29y ZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2No b2ZlbmlnDQpTZW50OiBBcHJpbC0yMS0xNiA1OjQzIEFNDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxj YWJvQHR6aS5vcmc+OyBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtjb3JlXSDwn5SUIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmct Y2Jvci1tYXBwaW5nLTAwDQoNCkhpIENhcnN0ZW4sIEhpIGFsbCwNCg0KSSB0aGluayB3ZSBhcmUg Z29pbmcgdG8gZmFzdCBoZXJlLg0KDQpXZSBoYXJkbHkgbWFrZSBhbnkgcHJvZ3Jlc3Mgd2l0aCB0 aGUgZXhpc3RpbmcgV0cgaXRlbXMgYnV0IHRoZW4gd2UgYWRkIGEgbnVtYmVyIG9mIG5ldyBpdGVt cyB0aGF0IGFyZSBiYXJlbHkgdW5kZXJzdG9vZC4NCg0KVGhpcyBjYWxsIGZvciBhZG9wdGlvbiBp cyBub3QgYSBjYWxsIGZvciB0aGlzIGRvY3VtZW50IHRoaXMgaXMgYSBxdWVzdGlvbiB3aGV0aGVy IHdlIHdhbnQgdG8gd29yayBvbiB0aGUgZm9sbG93aW5nIHR3byB0eXBlcyBvZiB0aGluZ3M6DQoN CmEpIGEgZGF0YSBtb2RlbGxpbmcgbGFuZ3VhZ2UgKFlhbmcpIGZvciB1c2Ugd2l0aCBJb1Qgb2Jq ZWN0cyAod2hpY2ggaW4gY2FzZSBvZiBJb1QgYXJlIGxhcmdlbHkgZGVmaW5lZCBlbHNld2hlcmUp LCBhbmQNCg0KYikgcmUtdXNlIGEgcHJvdG9jb2wgbWFjaGluZXJ5IG9yaWdpbmFsbHkgZGVmaW5l ZCBmb3IgbmV0d29yayBtYW5hZ2VtZW50IGFyb3VuZCBOZXRjb25mICh3aGljaCBtYXkgbm93IGJl IGNvbnZlcnRlZCB0byBDb0FQIGFuZCBDQk9SIHVzYWdlKS4NCg0KSSBoYXZlIHNwZW50IHNvbWUg dGltZSB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGF0IHRoZSBpbXBsaWNhdGlvbnMgYXJlIGFuZCAo dGhhdCdzIGEgYm9sZCBzdGF0ZW1lbnQpIGRvdWJ0IHRoYXQgbW9zdCBXRyBwYXJ0aWNpcGFudHMg KGV4Y2VwdCBmb3IgdGhlIGF1dGhvcnMgb2YgdGhlIGRvY3VtZW50cykgcmVhbGx5IHVuZGVyc3Rh bmQgd2hhdCB0aGlzIHJlYWxseSBtZWFucy4NCg0KSGVyZSBhcmUgdGhlIGNsYWltczoNCg0KMSkg SW9UIHdpbGwgcmUtdXNlIG1hbnkgb2YgdGhlIG9iamVjdHMgZGVmaW5lZCBmb3IgbmV0d29yayBt YW5hZ2VtZW50Lg0KDQoyKSBUaGVyZSBpcyBhIG5lZWQgZm9yIGEgZm9ybWFsIGxhbmd1YWdlIHRv IGRlc2NyaWJlIHRoZSBkYXRhIG1vZGVsLg0KDQozKSBUaGVyZSBpcyBhIHZhbHVlIGluIGdlbmVy YXRpbmcgY29kZSB1c2luZyB0aGF0IGZvcm1hbCBkYXRhIG1vZGVsIGRlc2NyaXB0aW9uLg0KDQo0 KSBZYW5nIChhcyBhIGRhdGEgbW9kZWxsaW5nIGxhbmd1YWdlKSBhbmQgdGhlIHJlbGF0ZWQgcHJv dG9jb2xzIGFyZSBhIGdvb2QgbWF0Y2ggZm9yIHRoZSByZXF1aXJlbWVudHMgcGVvcGxlIGhhdmUu DQoNCkFyZSB0aGVzZSBjbGFpbXMgYWN0dWFsbHkgdHJ1ZT8NCg0KR2l2ZW4gdGhhdCB3ZSBhcmUg bGF0ZSBhdCB0aGUgcGFydHkgYW5kIG90aGVyIG9yZ2FuaXphdGlvbnMgaGF2ZSBkb25lIGEgZmFp ciBhbW91bnQgb2Ygd29yayBpbiB0aGF0IHNwYWNlIGFscmVhZHkgSSBhbSB3b25kZXJpbmcgd2hl dGhlciB3ZSBoYXZlIGRvbmUgb3VyIGhvbWUgd29yayBvZiBhbmFseXNpcyB0aGUgZXhpc3Rpbmcg bGFuZHNjYXBlIG9yIHdoZXRoZXIgd2UgYXJlIGp1c3QgaW50ZXJlc3RlZCB0byBhZGQgYW5vdGhl ciBzZXQgb2Ygc3RhbmRhcmRzIHRvIHRoZSBtaXguDQoNCkkgaGF2ZSBteSBvcGluaW9uIGFib3V0 IHRoZSBjbGFpbXMgYW5kIEkgd291bGQgbGlrZSB0byBzaGFyZSB0aGVtIHdpdGggeW91Lg0KDQpS ZWdhcmRpbmcgKDEpIG9uIHRoZSByZS11c2UgYXJndW1lbnQuIEkgZG8gbm90IGJlbGlldmUgdGhh dCB0aGUgZXhpc3RpbmcsIGFscmVhZHkgc3RhbmRhcmRpemVkIG9iamVjdHMgZGVmaW5lZCBmb3Ig bmV0d29yayBtYW5hZ2VtZW50IGFyZSBhIGdvb2QgZml0IGZvciB3aGF0IHdlIGFyZSBkb2luZyBp biBJb1QuIEkgaGF2ZSBub3Qgc2VlbiB0aGUgZXhhbXBsZXMgd2hlcmUgdGhlcmUgaXMgcmUtdXNl LiBBcyBpbGx1c3RyYXRlZCBiZWxvdywgSSBhbSBleHBvc2luZyBteSBzZW5zb3JzLCBidXR0b25z LCBhbmQgTEVEcyB0byBvdXRzaWRlIHdvcmxkIHJhdGhlciB0aGFuIG5ldHdvcmsgaW50ZXJmYWNl cyBhbmQgYWxpa2UuIEkgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IHRoZSB3b3JsZCBpcyBmYXIgbW9y ZSBjb21wbGV4IHdpdGggcm91dGVycyBhbmQgc3dpdGNoZXMgdGhhdCBoYXZlIG1hbnkgcG9ydHMg YW5kIGxvdHMgb2YgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiBUaGV5IGFyZSBhbHNvIHJ1bm5p bmcgcmVndWxhciBvcGVyYXRpbmcgc3lzdGVtcywgbGlrZSBMaW51eC4NCg0KUmVnYXJkaW5nICgy KSBvbiB0aGUgdXNlIG9mIGZvcm1hbCBsYW5ndWFnZXMuIEl0IHNlZW1zIHRoYXQgbW9zdCBvcmdh bml6YXRpb25zIGFyZSB1c2luZyBmb3JtYWwgbGFuZ3VhZ2VzIGZvciBkZXNjcmliaW5nIHRoZWly IG9iamVjdCBkZWZpbml0aW9ucyBhbHJlYWR5IHRvZGF5LiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0 aGF0IHRoZXNlIGZvcm1hbCBsYW5ndWFnZXMgZG8gbm90IHByb3ZpZGUgYSBsb3Qgb2YgdmFsdWUg aW4gZ2VuZXJhbCBidXQgdXNpbmcgc29tZXRoaW5nIHRoYXQgaXMgZWFzeSBmb3IgaHVtYW5zIHRv IHdyaXRlIGFuZCByZWFkIGlzIHNvbWV0aGluZyBJIG1heSBiZSBPSyB3aXRoLg0KUGFydGljdWxh cmx5IHRoZSBleGFtcGxlIGJlbG93IHNob3dzIHRoYXQgYWxsIEkgbmVlZCBhcyBhIGRldmVsb3Bl ciBpcyB2ZXJ5IGxpdHRsZS4gSW9UIGRldmljZXMgdHlwaWNhbGx5IGRvIG5vdCBoYXZlIG1hbnkg c2Vuc29ycyBhbmQgdGhlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgaXMgZWxzZXdoZXJlICh3 aXRoIHRoZSBvcGVyYXRpbmcgc3lzdGVtLCB0aGUgdG9vbCBjaGFpbiwgYW5kIHZhcmlvdXMgbG93 IHBvd2VyIHNldHRpbmdzKS4NCg0KUmVnYXJkaW5nICgzKSBvbiB0aGUgdmFsdWUgb2YgY29kZSBn ZW5lcmF0aW9uLg0KDQpJIGFtIGN1cnJlbnRseSBpbiB0aGUgcHJvY2VzcyBvZiB3cml0aW5nIGEg bmV3IHR1dG9yaWFsIGZvciBhIGRldmVsb3BlciB3b3Jrc2hvcCBob3N0ZWQgYnkgdGhlIE9wZW4g TW9iaWxlIEFsbGlhbmNlIChPTUEpLCBzZWUgaHR0cDovL29wZW5tb2JpbGVhbGxpYW5jZS5vcmcv ZnJlZS1oYW5kcy1vbi10cmFpbmluZy1mb3ItaW90LWRldmVsb3BlcnMtd2l0aC1vbWEtbHdtMm0t YW5kLWFybS1iYXNlZC1taWNyb3Byb2Nlc3NvcnMvDQoNCkkgYW0gdXNpbmcgcmVndWxhciBJb1Qg aGFyZHdhcmUsIG5hbWVseSB0aGUgSzY0RiBib2FyZCB3aXRoIG9uYm9hcmQgc2Vuc29ycywgbmFt ZWx5IGFuIGFjY2VsZXJvbWV0ZXIgYW5kIG1hZ25ldG9tZXRlciwgYW4gUkdCIExFRCwgYW5kIHR3 byBidXR0b25zLiBUaGUgc2Vuc29ycyBhcmUgY29ubmVjdGVkIHVzaW5nIEkyQyBhbmQgYXJlIGNl cnRhaW5seSBub3QgYW1vbmcgdGhlIG1vc3Qgc2ltcGxpc3RpYyAod2hpY2ggdGhlIGRhdGEgc2hl ZXQgb2YgYWxtb3N0IDEwMCBwYWdlcyBjYW4gZWFzaWx5IHRlbGwgeW91KS4NCg0KSW4gdGhlIHBy b2Nlc3Mgb2Ygd3JpdGluZyBjb2RlIEkgbmVlZCB0byBkbyB0aGUgZm9sbG93aW5nOg0KDQoqIEZp Z3VyZSBvdXQgaG93IHRvIGNvbm5lY3QgdG8gdGhlIHNlbnNvcnMgdXNpbmcgSTJDLg0KDQoqIExl YXJuIGhvdyB0aGUgc2Vuc29yIHdvcmtzLCBob3cgdG8gY29uZmlndXJlIHRoZSBzZW5zb3IgdG8g ZG8gd2hhdCBJIHdhbnQsIGFuZCB0byBjb252ZXJ0IHRoZSByYXcgc2Vuc29yIGRhdGEgaW50byBz b21ldGhpbmcgc3VpdGFibGUgZm9yIG15IGFwcGxpY2F0aW9uLiBPbmUgY2FuIG9ubHkgaG9wZSB0 byBmaW5kIGEgbGlicmFyeSB0aGF0IGRvZXMgdGhlc2UgdGhpbmdzIGFscmVhZHkgYW5kIHRvIG9u bHkgaGF2ZSB0byBhZGp1c3QgdGhlIHNldHRpbmdzIHJhdGhlciB0aGFuIHdyaXRpbmcgZXZlcnl0 aGluZyBmcm9tIHNjcmF0Y2guIFRoYXQgdHlwaWNhbGx5IHRha2VzIGEgbG90IG9mIHRpbWUuDQoN CiogRGV0ZXJtaW5lIHdoZXRoZXIgaXMgYSBzdWl0YWJsZSBvYmplY3QgZGVmaW5pdGlvbiBhbHJl YWR5IGF2YWlsYWJsZS4NCkluIG15IGNhc2UgSSBhbSBsb29raW5nIGF0IHRoZSBPTU5BIHJlZ2lz dHJ5ICh3aGljaCBoYXMgYWxzbyBiZWVuIHBvcHVsYXRlZCB3aXRoIHRoZSBvYmplY3RzIGZyb20g dGhlIElQU08gQWxsaWFuY2UpLiBIZXJlIGFyZSB0aGUgcmVnaXN0ZXJlZCBvYmplY3RzOg0KaHR0 cDovL3RlY2huaWNhbC5vcGVubW9iaWxlYWxsaWFuY2Uub3JnL1RlY2huaWNhbC90ZWNobmljYWwt aW5mb3JtYXRpb24vb21uYS9saWdodHdlaWdodC1tMm0tbHdtMm0tb2JqZWN0LXJlZ2lzdHJ5DQoN CkluIGNhc2Ugb2YgdGhlIEFjY2VsZXJvbWV0ZXIgYW5kIHRoZSBNYWduZXRvbWV0ZXIgSSBhbSBs dWNreSBzaW5jZSB0aG9zZSBoYXZlIGFscmVhZHkgYmVlbiBkZWZpbmVkLiBJIGRvbid0IG5lZWQg dG8gZGVmaW5lIG15IG93biBvYmplY3RzLCB3aGljaCBpcyBhIHNpbXBsZSB0YXNrIGdpdmVuIHRo ZSBuZXcgT01BIG9iamVjdCBlZGl0b3IgaHR0cDovL2RldnRvb2xraXQub3Blbm1vYmlsZWFsbGlh bmNlLm9yZy9PRWRpdG9yL0RlZmF1bHQNCg0KKiBUaGVuLCBJIG5lZWQgdG8gYWRkIHRoZSBjb2Rl IGZvciB1c2Ugd2l0aCB0aGVtLiBIZXJlIGlzIHdoZXJlIHRoZSBmb3JtYWwgZGVzY3JpcHRpb24g b2YgdGhlIGRhdGEgbW9kZWwgY291bGQgaGVscCBtZSB0byBhdXRvbWF0aWNhbGx5IHByb2R1Y2Ug Y29kZS4NCg0KTm93LCB0aGlzIGlzIHRoZSBmdW5ueSB0aGluZzogdGhpcyBjb2RlIGFtb3VudHMg Zm9yIGFyb3VuZCA1IGxpbmVzLCBkZXBlbmRpbmcgb24gdGhlIEFQSSBhbmQgcHJvZ3JhbW1pbmcg bGFuZ3VhZ2UgeW91IGFyZSB1c2luZy4gTW9zdCBsaWtlbHkgdGhlIGNvZGUgZ2VuZXJhdGlvbiB3 aWxsIHByb2R1Y2Ugc29tZSBjb2RlIHRoYXQgeW91IGNhbm5vdCBkaXJlY3RseSB1c2UuDQoNCkhl cmUgaXMgd2hhdCBJIGhhdmUgdG8gd3JpdGUgb24gdGhlIElvVCBzaWRlOg0KDQotLS0tDQoNCi8v IENyZWF0ZSBvYmplY3QgJzMzMTMnID0gJ0FjY2VsZXJvbWV0ZXInDQphY2Nfb2JqZWN0ID0gTTJN SW50ZXJmYWNlRmFjdG9yeTo6Y3JlYXRlX29iamVjdCgiMzMxMyIpOw0KDQpNMk1PYmplY3RJbnN0 YW5jZSogYWNjX2luc3QgPSBhY2Nfb2JqZWN0LT5jcmVhdGVfb2JqZWN0X2luc3RhbmNlKCk7DQoN Ck0yTVJlc291cmNlKiBhY2NfeF9yZXMgPSBhY2NfaW5zdC0+Y3JlYXRlX2R5bmFtaWNfcmVzb3Vy Y2UoIjU3MDIiLCAiWCBWYWx1ZSIsTTJNUmVzb3VyY2VJbnN0YW5jZTo6RkxPQVQsIHRydWUgLyog b2JzZXJ2YWJsZSAqLyk7DQoNCk0yTVJlc291cmNlKiBhY2NfeV9yZXMgPSBhY2NfaW5zdC0+Y3Jl YXRlX2R5bmFtaWNfcmVzb3VyY2UoIjU3MDMiLCAiWSBWYWx1ZSIsTTJNUmVzb3VyY2VJbnN0YW5j ZTo6RkxPQVQsIHRydWUgLyogb2JzZXJ2YWJsZSAqLyk7DQoNCk0yTVJlc291cmNlKiBhY2Nfel9y ZXMgPSBhY2NfaW5zdC0+Y3JlYXRlX2R5bmFtaWNfcmVzb3VyY2UoIjU3MDQiLCAiWiBWYWx1ZSIs TTJNUmVzb3VyY2VJbnN0YW5jZTo6RkxPQVQsIHRydWUgLyogb2JzZXJ2YWJsZSAqLyk7DQoNCi0t LS0tDQoNCkkgZmVhciB0aGF0IHdlIGFyZSBvcHRpbWl6aW5nIGZvciBzb21ldGhpbmcgdGhhdCBk b2VzIG5vdCB0YWtlIGEgbG9uZyB0aW1lIGFueXdheS4gSXQgd2lsbCB0YWtlIGxvbmdlciB0byBm ZXRjaCB0aGUgcmVsZXZhbnQgWWFuZyBmaWxlLCB0byB1c2UgdGhlIHRvb2xzIHRvIGdlbmVyYXRl IHRoZSBjb2RlIGFuZCB0byBpbnRlZ3JhdGUgaXQgaW50byB0aGUgZXhpc3RpbmcgY29kZSB0aGFu IHRvIGp1c3Qgd3JpdGUgdGhlc2UgZmV3IGxpbmVzIHlvdXJzZWxmLg0KDQpXaGF0IHRoZSBhYm92 ZSBleGFtcGxlIGRvZXMgbm90IHV0aWxpemUgcG90ZW50aWFsIGNvZGUgZ2VuZXJhdGlvbiBmb3Ig dGhlIGFjdHVhbCBpbnRlcmFjdGlvbiBtb2RlbC4gSW4gbXkgY2FzZSBteSBjb2RlIGlzIGhhcmQt d2lyZWQgdG8gdXNlIExXTTJNLg0KDQpTaW5jZSBJIGhhdmUgbm90IHlldCBzZWVuIGEgbWVhbmlu Z2Z1bCBleGFtcGxlIG9mIFlhbmcgZm9yIHRoZSBJb1QgZW52aXJvbm1lbnQgSSBhbHNvIGhhdmVu J3Qgc2VlbiBvbmUgdGhhdCBwcm9kdWNlcyBtZWFuaW5nZnVsIGNvZGUgZm9yIHRoZSBpbnRlcmFj dGlvbiBtb2RlbCBlaXRoZXIuDQoNClJlZ2FyZGluZyAoNCkgY29uY2VybmluZyBZYW5nIGFzIGEg ZGF0YSBtb2RlbGxpbmcgbGFuZ3VhZ2UgKHZzLiBvdGhlciBsYW5ndWFnZXMgYWxzbyBjb25zaWRl cmVkIGJ5IHRoZSBJb1QgY29tbXVuaXRpZXMpLiBBcyBQYXVsIG5vdGVkIHRoZXJlIGFyZSBvdGhl ciBsYW5ndWFnZXMgaW4gdG93biBhbmQgSSBwZXJzb25hbGx5IGRvIG5vdCBrbm93IHdoZXRoZXIg dGhlIGZlYXR1cmVzIG9mZmVyZWQgYnkgWWFuZyBhcmUgYmV0dGVyIG9yIGVxdWFsIHRvIHRob3Nl IG9mZmVyZWQgYnkgdGhlIG90aGVyIGxhbmd1YWdlcy4gSSBjZXJ0YWlubHkgaGF2ZW4ndCBkb25l IHRoYXQgYW5hbHlzaXMuDQoNCkFzIGEgY29uY2x1ZGluZyByZW1hcmsgSSB3b3VsZCBsaWtlIHRv IHNheSB0aGF0IHdoaWxlIG15IGN1cnJlbnQgYXNzZXNzbWVudCBtYXkgc291bmQgbmVnYXRpdmUg SSBhbSBoYXBweSB0byBsZWFybiBtb3JlIGFib3V0IHRoaXMgdG9waWMgYW5kIG1pZ2h0IGdldCBj b252aW5jZWQgdGhhdCBZYW5nIGlzIHRoZSByaWdodCB0b29sLiBDdXJyZW50bHksIEkganVzdCBo YXZlbid0IHJlYWNoZWQgdGhhdCBsZXZlbCB5ZXQgYW5kIEkgY2FuIGNsYWltIHRoYXQgSSBoYXZl IHNwZW50IHNvbWUgdGltZSBsb29raW5nIGF0IHRoaXMgdG9waWMgYWxyZWFkeS4NCg0KQ2lhbw0K SGFubmVzDQoNCg0KT24gMDQvMTAvMjAxNiAwMjoyMiBQTSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3Rl Og0KPiBJbiBCdWVub3MgQWlyZXMsIHdlIGRpc2N1c3NlZCB0aGUgYWRvcHRpb24gb2YNCj4gZHJh ZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYnV0IG5vdCBlbm91Z2ggcGVv cGxlIGhhZCANCj4gcmVhZCB0aGUgZG9jdW1lbnQgdG8gZ28gZm9yIGFuIGluLXJvb20gY29uc2Vu c3VzIGNhbGwuDQo+IA0KPiBUaGlzIGlzIGEgdHdvLXdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb2YN Cj4gZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYXMgYSBXRyBkb2N1 bWVudCBvZiBDb1JFLg0KPiBTcGVjaWZpY2FsbHksIGlmIHlvdSAoMSkgc3VwcG9ydCBvciAoMikg aGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhpcyANCj4gZGVjaXNpb24sIHBsZWFzZSBzcGVhayB1cCBv biB0aGUgbWFpbGluZyBsaXN0IGJ5IDIwMTYtMDQtMjQuDQo+IA0KPiBOb3RlIHRoYXQgdGhpcyB3 b3JrIGlzIGV4cGxpY2l0bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciwgc28gDQo+IGRpc2N1c3Np b25zIG9mIHdoaWNoIFdHIHNob3VsZCB3b3JrIG9uIHRoaXMgYXJlIG9mZi10b3BpYy4NCj4gDQo+ IEFzIGFsd2F5cywgYWRvcHRpb24gb2YgYSBkb2N1bWVudCBhcyBhIFdHIGRvY3VtZW50IGlzIG5v dCBhIHZvdGUgb24gDQo+IHdoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFzdC1jYWxs IHN0YXRlOyB0aGUgaW50ZW50aW9uIGlzIHRvIA0KPiB3b3JrIG9uIHRoZSBXRyBkb2N1bWVudCBh ZnRlciBhZG9wdGlvbiBmb3IgYSB3aGlsZSB0byBnZXQgaXQgcmVhZHkgZm9yIA0KPiBsYXN0IGNh bGwuICBJZiB5b3Ugd2FudCB0byBjb21iaW5lIHlvdXIgc3VwcG9ydC9vYmplY3Rpb24gd2l0aCAN Cj4gdGVjaG5pY2FsIGNvbW1lbnRzLCB0aGlzIGlzIGNlcnRhaW5seSB3ZWxjb21lIHNvIHdlIGNh biBhY2NlbGVyYXRlIHRoYXQgcHJvY2Vzcy4NCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUg bWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQo+IA0KDQo= From nobody Thu Apr 21 10:48:14 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC6C12E863 for ; Thu, 21 Apr 2016 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 lT0Z581Jdl-r for ; Thu, 21 Apr 2016 10:48:11 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7602912D70B for ; Thu, 21 Apr 2016 10:48:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3D2A511CA; Thu, 21 Apr 2016 19:48:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tG7zDOEjLfwY; Thu, 21 Apr 2016 19:47:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Apr 2016 19:48:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9444920047; Thu, 21 Apr 2016 19:48:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Eokn4ZkLGoZh; Thu, 21 Apr 2016 19:48:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0D1420046; Thu, 21 Apr 2016 19:48:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 222F43AAD1A4; Thu, 21 Apr 2016 19:48:06 +0200 (CEST) Date: Thu, 21 Apr 2016 19:48:06 +0200 From: Juergen Schoenwaelder To: Michel Veillette Message-ID: <20160421174806.GA8710@elstar.local> Mail-Followup-To: Michel Veillette , Hannes Tschofenig , "core@ietf.org WG" References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 17:48:14 -0000 On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote: > > First, LWM2M have its own modeling language encoded in xml. > A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang. > A simple xml transform can probably do the conversion between the two without any lost. > LWM2M just have a simpler (subset) modeling language. > These are pretty bold statements. Claiming something is simple and knowing something is simple are sometimes different things. Have you worked throught the details? Is there a decent public definition of the 'simpler (subset) modeling language'? And with public I mean public, not hidden behind all sorts of registration walls. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 21 11:30:37 2016 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965B12E210 for ; Thu, 21 Apr 2016 11:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8zpCVoseXzG for ; Thu, 21 Apr 2016 11:30:32 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3029F12DE9E for ; Thu, 21 Apr 2016 11:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20729; q=dns/txt; s=iport; t=1461263431; x=1462473031; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to; bh=6EUQ6eWbf9KliMKTSzDDm5arYv1abkDHnjDg8A2VqEs=; b=ed3eDPmD1x5tIhtOfkjl+BkDN3M7RAdKlrp+9wN9dM3LjalioaC6f9w9 r9EaHMNDMbikMY2m4bmYyBWAyd1X/s6PyPGbGYxsuEcqWM7GJwPbtlLCQ CDk7lqdIF6XnqNtgP7edIfGyHPXPjdS7gvlb6Ah4Z+NchOZeffZm88W1k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAgD7GxlX/xbLJq1ehAt9tQmDfHYBD?= =?us-ascii?q?YF0FwEOgiiDQAKBahQBAQEBAQEBZSeEQgEBBAEBARoKRwoRCQIYCRYPCQMCAQI?= =?us-ascii?q?BFTATBgIBAQUTiA4OkXGjOIsAAQEBAQYBAQEBARuGIYRLhCOFcgWYD4V7iBmBZ?= =?us-ascii?q?k6Df4MGI4U0jy4eAQFChAUgMIc7JYEWAQEB?= X-IronPort-AV: E=Sophos;i="5.24,513,1454976000"; d="scan'208,217";a="676859129" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 18:30:24 +0000 Received: from [10.131.65.152] (dhcp-10-131-65-152.cisco.com [10.131.65.152]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3LIUOin013862 for ; Thu, 21 Apr 2016 18:30:24 GMT References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> To: core@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: <57191C3F.6030004@cisco.com> Date: Thu, 21 Apr 2016 14:30:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5718A09E.7040607@gmx.net> Content-Type: multipart/alternative; boundary="------------020503060707070602090602" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 18:30:35 -0000 This is a multi-part message in MIME format. --------------020503060707070602090602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Hannes A few related comments.... re: 2 and 3. I do see a machine consumable interface / resource definition as useful. At least as the contract both ends of the communication will code. Recent Cisco experience underlines co-developing using prose based descriptions is highly error prone (I not surprised). I'm further an advocate of using these interface descriptions for code gen, doc gen, and conformance testing tools (when certification is being performed). The pro IDL macro points have not changed over the years: Corba, COM, WSDL, WADL, and now the IoT space. re: 4. This is a tough one. I struggle with YANG for IoT. Acknowledging it is the IETF's baby. But I see no traction out at the far edge of IoT. Different dialects? Tooling support (editors, validators, code gen, doc gen, etc)? Cisco is putting effort into the RAML ecosystem, OCF being a first example of that. http://www.oneiota.org/documents?filter[media_type]=application%2Framl%2Byaml I better understand RAML, but am happy to be enlightened re: YANG for IoT endpoints. Does anyone have a side by side example worked out? Interface definition to running code? Cheers On 4/21/2016 5:42 AM, Hannes Tschofenig wrote: > Hi Carsten, Hi all, > > I think we are going to fast here. > > We hardly make any progress with the existing WG items but then we add a > number of new items that are barely understood. > > This call for adoption is not a call for this document this is a > question whether we want to work on the following two types of things: > > a) a data modelling language (Yang) for use with IoT objects (which in > case of IoT are largely defined elsewhere), and > > b) re-use a protocol machinery originally defined for network management > around Netconf (which may now be converted to CoAP and CBOR usage). > > I have spent some time trying to figure out what the implications are > and (that's a bold statement) doubt that most WG participants (except > for the authors of the documents) really understand what this really means. > > Here are the claims: > > 1) IoT will re-use many of the objects defined for network management. > > 2) There is a need for a formal language to describe the data model. > > 3) There is a value in generating code using that formal data model > description. > > 4) Yang (as a data modelling language) and the related protocols are a > good match for the requirements people have. > > Are these claims actually true? > > Given that we are late at the party and other organizations have done a > fair amount of work in that space already I am wondering whether we have > done our home work of analysis the existing landscape or whether we are > just interested to add another set of standards to the mix. > > I have my opinion about the claims and I would like to share them with you. > > Regarding (1) on the re-use argument. I do not believe that the > existing, already standardized objects defined for network management > are a good fit for what we are doing in IoT. I have not seen the > examples where there is re-use. As illustrated below, I am exposing my > sensors, buttons, and LEDs to outside world rather than network > interfaces and alike. I fully understand that the world is far more > complex with routers and switches that have many ports and lots of > configuration parameters. They are also running regular operating > systems, like Linux. > > Regarding (2) on the use of formal languages. It seems that most > organizations are using formal languages for describing their object > definitions already today. I personally believe that these formal > languages do not provide a lot of value in general but using something > that is easy for humans to write and read is something I may be OK with. > Particularly the example below shows that all I need as a developer is > very little. IoT devices typically do not have many sensors and the > implementation complexity is elsewhere (with the operating system, the > tool chain, and various low power settings). > > Regarding (3) on the value of code generation. > > I am currently in the process of writing a new tutorial for a developer > workshop hosted by the Open Mobile Alliance (OMA), see > http://openmobilealliance.org/free-hands-on-training-for-iot-developers-with-oma-lwm2m-and-arm-based-microprocessors/ > > I am using regular IoT hardware, namely the K64F board with onboard > sensors, namely an accelerometer and magnetometer, an RGB LED, and two > buttons. The sensors are connected using I2C and are certainly not among > the most simplistic (which the data sheet of almost 100 pages can easily > tell you). > > In the process of writing code I need to do the following: > > * Figure out how to connect to the sensors using I2C. > > * Learn how the sensor works, how to configure the sensor to do what I > want, and to convert the raw sensor data into something suitable for my > application. One can only hope to find a library that does these things > already and to only have to adjust the settings rather than writing > everything from scratch. That typically takes a lot of time. > > * Determine whether is a suitable object definition already available. > In my case I am looking at the OMNA registry (which has also been > populated with the objects from the IPSO Alliance). Here are the > registered objects: > http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry > > In case of the Accelerometer and the Magnetometer I am lucky since those > have already been defined. I don't need to define my own objects, which > is a simple task given the new OMA object editor > http://devtoolkit.openmobilealliance.org/OEditor/Default > > * Then, I need to add the code for use with them. Here is where the > formal description of the data model could help me to automatically > produce code. > > Now, this is the funny thing: this code amounts for around 5 lines, > depending on the API and programming language you are using. Most likely > the code generation will produce some code that you cannot directly use. > > Here is what I have to write on the IoT side: > > ---- > > // Create object '3313' = 'Accelerometer' > acc_object = M2MInterfaceFactory::create_object("3313"); > > M2MObjectInstance* acc_inst = acc_object->create_object_instance(); > > M2MResource* acc_x_res = acc_inst->create_dynamic_resource("5702", "X > Value",M2MResourceInstance::FLOAT, true /* observable */); > > M2MResource* acc_y_res = acc_inst->create_dynamic_resource("5703", "Y > Value",M2MResourceInstance::FLOAT, true /* observable */); > > M2MResource* acc_z_res = acc_inst->create_dynamic_resource("5704", "Z > Value",M2MResourceInstance::FLOAT, true /* observable */); > > ----- > > I fear that we are optimizing for something that does not take a long > time anyway. It will take longer to fetch the relevant Yang file, to use > the tools to generate the code and to integrate it into the existing > code than to just write these few lines yourself. > > What the above example does not utilize potential code generation for > the actual interaction model. In my case my code is hard-wired to use > LWM2M. > > Since I have not yet seen a meaningful example of Yang for the IoT > environment I also haven't seen one that produces meaningful code for > the interaction model either. > > Regarding (4) concerning Yang as a data modelling language (vs. other > languages also considered by the IoT communities). As Paul noted there > are other languages in town and I personally do not know whether the > features offered by Yang are better or equal to those offered by the > other languages. I certainly haven't done that analysis. > > As a concluding remark I would like to say that while my current > assessment may sound negative I am happy to learn more about this topic > and might get convinced that Yang is the right tool. Currently, I just > haven't reached that level yet and I can claim that I have spent some > time looking at this topic already. > > Ciao > Hannes > > > On 04/10/2016 02:22 PM, Carsten Bormann wrote: >> In Buenos Aires, we discussed the adoption of >> draft-veillette-core-yang-cbor-mapping-00 but not enough people had read >> the document to go for an in-room consensus call. >> >> This is a two-week call for adoption of >> draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE. >> Specifically, if you (1) support or (2) have an objection to this >> decision, please speak up on the mailing list by 2016-04-24. >> >> Note that this work is explicitly covered by our charter, so discussions >> of which WG should work on this are off-topic. >> >> As always, adoption of a document as a WG document is not a vote on >> whether we already have reached last-call state; the intention is to >> work on the WG document after adoption for a while to get it ready for >> last call. If you want to combine your support/objection with technical >> comments, this is certainly welcome so we can accelerate that process. >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------020503060707070602090602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Hannes

A few related comments....

re: 2 and 3.  I do see a machine consumable interface / resource definition as useful.  At least as the contract both ends of the communication will code.  Recent Cisco experience underlines co-developing using prose based descriptions is highly error prone (I not surprised).  I'm further an advocate of using these interface descriptions for code gen, doc gen, and conformance testing tools (when certification is being performed).  The pro IDL macro points have not changed over the years: Corba, COM, WSDL, WADL, and now the IoT space.

re: 4.  This is a tough one.  I struggle with YANG for IoT.  Acknowledging it is the IETF's baby.  But I see no traction out at the far edge of IoT.   Different dialects?  Tooling support (editors, validators, code gen, doc gen, etc)? Cisco is putting effort into the RAML ecosystem, OCF being a first example of that. 

http://www.oneiota.org/documents?filter[media_type]=application%2Framl%2Byaml

I better understand RAML, but am happy to be enlightened re: YANG for IoT endpoints.  Does anyone have a side by side example worked out?  Interface definition to running code?

Cheers


On 4/21/2016 5:42 AM, Hannes Tschofenig wrote:
Hi Carsten, Hi all,

I think we are going to fast here.

We hardly make any progress with the existing WG items but then we add a
number of new items that are barely understood.

This call for adoption is not a call for this document this is a
question whether we want to work on the following two types of things:

a) a data modelling language (Yang) for use with IoT objects (which in
case of IoT are largely defined elsewhere), and

b) re-use a protocol machinery originally defined for network management
around Netconf (which may now be converted to CoAP and CBOR usage).

I have spent some time trying to figure out what the implications are
and (that's a bold statement) doubt that most WG participants (except
for the authors of the documents) really understand what this really means.

Here are the claims:

1) IoT will re-use many of the objects defined for network management.

2) There is a need for a formal language to describe the data model.

3) There is a value in generating code using that formal data model
description.

4) Yang (as a data modelling language) and the related protocols are a
good match for the requirements people have.

Are these claims actually true?

Given that we are late at the party and other organizations have done a
fair amount of work in that space already I am wondering whether we have
done our home work of analysis the existing landscape or whether we are
just interested to add another set of standards to the mix.

I have my opinion about the claims and I would like to share them with you.

Regarding (1) on the re-use argument. I do not believe that the
existing, already standardized objects defined for network management
are a good fit for what we are doing in IoT. I have not seen the
examples where there is re-use. As illustrated below, I am exposing my
sensors, buttons, and LEDs to outside world rather than network
interfaces and alike. I fully understand that the world is far more
complex with routers and switches that have many ports and lots of
configuration parameters. They are also running regular operating
systems, like Linux.

Regarding (2) on the use of formal languages. It seems that most
organizations are using formal languages for describing their object
definitions already today. I personally believe that these formal
languages do not provide a lot of value in general but using something
that is easy for humans to write and read is something I may be OK with.
Particularly the example below shows that all I need as a developer is
very little. IoT devices typically do not have many sensors and the
implementation complexity is elsewhere (with the operating system, the
tool chain, and various low power settings).

Regarding (3) on the value of code generation.

I am currently in the process of writing a new tutorial for a developer
workshop hosted by the Open Mobile Alliance (OMA), see
http://openmobilealliance.org/free-hands-on-training-for-iot-developers-with-oma-lwm2m-and-arm-based-microprocessors/

I am using regular IoT hardware, namely the K64F board with onboard
sensors, namely an accelerometer and magnetometer, an RGB LED, and two
buttons. The sensors are connected using I2C and are certainly not among
the most simplistic (which the data sheet of almost 100 pages can easily
tell you).

In the process of writing code I need to do the following:

* Figure out how to connect to the sensors using I2C.

* Learn how the sensor works, how to configure the sensor to do what I
want, and to convert the raw sensor data into something suitable for my
application. One can only hope to find a library that does these things
already and to only have to adjust the settings rather than writing
everything from scratch. That typically takes a lot of time.

* Determine whether is a suitable object definition already available.
In my case I am looking at the OMNA registry (which has also been
populated with the objects from the IPSO Alliance). Here are the
registered objects:
http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry

In case of the Accelerometer and the Magnetometer I am lucky since those
have already been defined. I don't need to define my own objects, which
is a simple task given the new OMA object editor
http://devtoolkit.openmobilealliance.org/OEditor/Default

* Then, I need to add the code for use with them. Here is where the
formal description of the data model could help me to automatically
produce code.

Now, this is the funny thing: this code amounts for around 5 lines,
depending on the API and programming language you are using. Most likely
the code generation will produce some code that you cannot directly use.

Here is what I have to write on the IoT side:

----

// Create object '3313' = 'Accelerometer'
acc_object = M2MInterfaceFactory::create_object("3313");

M2MObjectInstance* acc_inst = acc_object->create_object_instance();

M2MResource* acc_x_res = acc_inst->create_dynamic_resource("5702", "X
Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_y_res = acc_inst->create_dynamic_resource("5703", "Y
Value",M2MResourceInstance::FLOAT, true /* observable */);

M2MResource* acc_z_res = acc_inst->create_dynamic_resource("5704", "Z
Value",M2MResourceInstance::FLOAT, true /* observable */);

-----

I fear that we are optimizing for something that does not take a long
time anyway. It will take longer to fetch the relevant Yang file, to use
the tools to generate the code and to integrate it into the existing
code than to just write these few lines yourself.

What the above example does not utilize potential code generation for
the actual interaction model. In my case my code is hard-wired to use
LWM2M.

Since I have not yet seen a meaningful example of Yang for the IoT
environment I also haven't seen one that produces meaningful code for
the interaction model either.

Regarding (4) concerning Yang as a data modelling language (vs. other
languages also considered by the IoT communities). As Paul noted there
are other languages in town and I personally do not know whether the
features offered by Yang are better or equal to those offered by the
other languages. I certainly haven't done that analysis.

As a concluding remark I would like to say that while my current
assessment may sound negative I am happy to learn more about this topic
and might get convinced that Yang is the right tool. Currently, I just
haven't reached that level yet and I can claim that I have spent some
time looking at this topic already.

Ciao
Hannes


On 04/10/2016 02:22 PM, Carsten Bormann wrote:

In Buenos Aires, we discussed the adoption of
draft-veillette-core-yang-cbor-mapping-00 but not enough people had read
the document to go for an in-room consensus call.

This is a two-week call for adoption of
draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE.
Specifically, if you (1) support or (2) have an objection to this
decision, please speak up on the mailing list by 2016-04-24.

Note that this work is explicitly covered by our charter, so discussions
of which WG should work on this are off-topic.

As always, adoption of a document as a WG document is not a vote on
whether we already have reached last-call state; the intention is to
work on the WG document after adoption for a while to get it ready for
last call.  If you want to combine your support/objection with technical
comments, this is certainly welcome so we can accelerate that process.

Grüße, Carsten

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



      

      

      

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


    

    

  


--------------020503060707070602090602--


From nobody Thu Apr 21 11:39:37 2016
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 F37BB12DC70; Thu, 21 Apr 2016 11:39:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160421183934.19610.21814.idtracker@ietfa.amsl.com>
Date: Thu, 21 Apr 2016 11:39:34 -0700
Archived-At: 
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:39:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : A TCP and TLS Transport for the Constrained Application Protocol (CoAP)
        Authors         : Carsten Bormann
                          Simon Lemay
                          Valik Solorzano Barboza
                          Hannes Tschofenig
	Filename        : draft-ietf-core-coap-tcp-tls-02.txt
	Pages           : 14
	Date            : 2016-04-21

Abstract:
   The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
   underlying transport protocol.  The Constrained Application Protocol
   (CoAP), while inspired by HTTP, has been defined to make use of UDP
   instead of TCP.  Therefore, reliable delivery and a simple congestion
   control and flow control mechanism are provided by the message layer
   of the CoAP protocol.

   A number of environments benefit from the use of CoAP directly over a
   reliable byte stream such as TCP, which already provides these
   services.  This document defines the use of CoAP over TCP as well as
   CoAP over TLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-02


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

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


From nobody Thu Apr 21 11:40:44 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E412E5AF for ; Thu, 21 Apr 2016 11:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 feCyw-2cBaxj for ; Thu, 21 Apr 2016 11:40:40 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 4335C12E6C0 for ; Thu, 21 Apr 2016 11:40:40 -0700 (PDT)
Received: from localhost ([::1]:54428 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1atJWj-0000ni-Cn; Thu, 21 Apr 2016 11:40:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 21 Apr 2016 18:40:33 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/396#comment:2
Message-ID: <080.38d0bd68cc8b30f6f220dffbebf59ac5@trac.tools.ietf.org>
References: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org>
X-Trac-Ticket-ID: 396
In-Reply-To: <065.8fdd76888850930554160d95484c0360@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hannes.tschofenig@gmx.net, Hannes.Tschofenig@gmx.net, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #396 (coap-tcp-tls): L1 vs. L3 Encoding Approach
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:40:41 -0000

#396: L1 vs. L3 Encoding Approach

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolved in draft-ietf-core-coap-tcp-tls-02

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  Hannes.Tschofenig@gmx.net          |  hannes.tschofenig@gmx.net
     Type:  other technical          |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  coap-tcp-tls             |     Version:
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
core 


From nobody Thu Apr 21 11:41:42 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D493612E775; Thu, 21 Apr 2016 11:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 kEyqjW61ta2J; Thu, 21 Apr 2016 11:41:39 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 97F2E12E851; Thu, 21 Apr 2016 11:41:39 -0700 (PDT)
Received: from localhost ([::1]:54488 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1atJXn-0003FH-E2; Thu, 21 Apr 2016 11:41:39 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 21 Apr 2016 18:41:39 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/397#comment:1
Message-ID: <080.76ee841c02bfdc10a8092f0731899753@trac.tools.ietf.org>
References: <065.b1a2e6aa9c5600bacf4cf8ae258078b0@trac.tools.ietf.org>
X-Trac-Ticket-ID: 397
In-Reply-To: <065.b1a2e6aa9c5600bacf4cf8ae258078b0@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160421184139.97F2E12E851@ietfa.amsl.com>
Resent-Date: Thu, 21 Apr 2016 11:41:39 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #397 (coap-tcp-tls): CON usage with CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:41:41 -0000

#397: CON usage with CoAP over TCP

Changes (by cabo@tzi.org):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Resolved in draft-ietf-core-coap-tcp-tls-02

 The bits that could be set to an invalid value are now no longer sent.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-core-coap-
  Hannes.Tschofenig@gmx.net          |  tcp-tls@ietf.org
     Type:  protocol defect          |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  coap-tcp-tls             |     Version:
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
core 


From nobody Thu Apr 21 11:45:58 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D871812E200 for ; Thu, 21 Apr 2016 11:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 j2IeZUlEdqmQ for ; Thu, 21 Apr 2016 11:45:55 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08F412E177 for ; Thu, 21 Apr 2016 11:45:55 -0700 (PDT)
Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 1332BC5A6D; Thu, 21 Apr 2016 20:45:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ulcpRCpxr9Lc; Thu, 21 Apr 2016 20:45:52 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D4BF0C5A60; Thu, 21 Apr 2016 20:45:51 +0200 (CEST)
Message-ID: <57191FDD.2070701@tzi.org>
Date: Thu, 21 Apr 2016 20:45:49 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: core@ietf.org
References: <20160421183934.19610.21814.idtracker@ietfa.amsl.com>
In-Reply-To: <20160421183934.19610.21814.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [core] I-D Action: draft-ietf-core-coap-tcp-tls-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:45:58 -0000

This version reflects the consensus we had on moving to variant L3,
closing ticket #396.  As a side effect, #397 is now moot and has been
closed as well.

Next, we should be focusing on what kinds of signaling we need and how
to express it.  (There is also #387, where we still need to make a
decision.)

Grüße, Carsten


internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Constrained RESTful Environments of the IETF.
> 
>         Title           : A TCP and TLS Transport for the Constrained Application Protocol (CoAP)
>         Authors         : Carsten Bormann
>                           Simon Lemay
>                           Valik Solorzano Barboza
>                           Hannes Tschofenig
> 	Filename        : draft-ietf-core-coap-tcp-tls-02.txt
> 	Pages           : 14
> 	Date            : 2016-04-21
> 
> Abstract:
>    The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
>    underlying transport protocol.  The Constrained Application Protocol
>    (CoAP), while inspired by HTTP, has been defined to make use of UDP
>    instead of TCP.  Therefore, reliable delivery and a simple congestion
>    control and flow control mechanism are provided by the message layer
>    of the CoAP protocol.
> 
>    A number of environments benefit from the use of CoAP directly over a
>    reliable byte stream such as TCP, which already provides these
>    services.  This document defines the use of CoAP over TCP as well as
>    CoAP over TLS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 


From nobody Thu Apr 21 11:51:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F5412D736 for ; Thu, 21 Apr 2016 11:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 m995jocHipWI for ; Thu, 21 Apr 2016 11:51:20 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 59B4A12D672 for ; Thu, 21 Apr 2016 11:51:20 -0700 (PDT)
Received: from localhost ([::1]:55052 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1atJh9-0005Jj-Ol; Thu, 21 Apr 2016 11:51:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 21 Apr 2016 18:51:19 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/400
Message-ID: <052.7b80c895de0c0881e50e94763b17abfb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 400
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-block@ietf.org
Resent-Message-Id: <20160421185120.59B4A12D672@ietfa.amsl.com>
Resent-Date: Thu, 21 Apr 2016 11:51:20 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #400 (block): Give better guidance on message sizes for CoAP over TCP/TLS
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:51:22 -0000

#400: Give better guidance on message sizes for CoAP over TCP/TLS

 Section 4.1 discusses the effect of having CoAP over TCP/TLS on potential
 message sizes.
 But we are not really giving guidance here on whether we want to use this
 potential capability.

 If we want to open this up, we probably also need to include message sizes
 in the settings/capabilities mechanism

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-
  cabo@tzi.org           |  block@tools.ietf.org
     Type:  other        |     Status:  new
  technical              |  Milestone:
 Priority:  major        |    Version:
Component:  block        |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Thu Apr 21 11:53:55 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8337412DABC; Thu, 21 Apr 2016 11:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 W9zhbnpqU24O; Thu, 21 Apr 2016 11:53:45 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C1E5E12D177; Thu, 21 Apr 2016 11:53:42 -0700 (PDT)
Received: from localhost ([::1]:55136 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1atJjS-0005lM-M4; Thu, 21 Apr 2016 11:53:42 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 21 Apr 2016 18:53:42 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/400#comment:1
Message-ID: <067.f9c7fcfb4ce5996d349a287d81af21a7@trac.tools.ietf.org>
References: <052.7b80c895de0c0881e50e94763b17abfb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 400
In-Reply-To: <052.7b80c895de0c0881e50e94763b17abfb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160421185342.C1E5E12D177@ietfa.amsl.com>
Resent-Date: Thu, 21 Apr 2016 11:53:42 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #400 (coap-tcp-tls): Give better guidance on message sizes for CoAP over TCP/TLS
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 18:53:47 -0000

#400: Give better guidance on message sizes for CoAP over TCP/TLS

Changes (by cabo@tzi.org):

 * owner:  draft-ietf-core-block@tools.ietf.org => draft-ietf-core-coap-tcp-
     tls@ietf.org
 * component:  block => coap-tcp-tls


Comment:

 (Oops, this pointed to block and not coap-ever-tcp-tls.)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  cabo@tzi.org           |  tls@ietf.org
     Type:  other        |      Status:  new
  technical              |   Milestone:
 Priority:  major        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Thu Apr 21 12:48:00 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3A312DF6E for ; Thu, 21 Apr 2016 12:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP5bcEfSLiaD for ; Thu, 21 Apr 2016 12:47:57 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1108012DE97 for ; Thu, 21 Apr 2016 12:47:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IX4IhVMMEEOqPsdHL7Vf260hT+HX2XvRAvSQ5wL+op8=; b=JPmjCx7b2GwRM0BJg0Ua+HfdXe5uX7V0RaBOaeJVlG7BOI/F8gmRsZ1SNbWobEwCyM1XcjKxyLfIHqUHlfqcBGi9Ea4vlmzKiNoCQQkSmi1WuJTpDtd6S8LpI+FJnqxbRNju9SAKnDJbnn50JpibhPl84IrMJ+9ocBRJ3oN+A/I=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 19:47:53 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 19:47:53 +0000
From: Michel Veillette 
To: Juergen Schoenwaelder 
Thread-Topic: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
Thread-Index: AQHRm/X9d/034ye6rkCrz4BefXTDrJ+U0HzQ
Date: Thu, 21 Apr 2016 19:47:53 +0000
Message-ID: 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>
In-Reply-To: <20160421174806.GA8710@elstar.local>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: cc66aefb-b514-4b73-fae0-08d36a1dd415
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:XugZ5KiCVBJaKEe2ZNGpk1xoSdzve/utdDhkXORpK7MNs0+WQqdP3e9SSjh/FcL+7uiZFyqrKS7/e5EFGj/Hv19yvve9fgTfV6fkINacYH0KPAFklzeDEGlih55qwmlwi3WgoBQ+xzos8xddnw/CFGOQ9/G7m0Fa9hF025lAC7aPhOAVfatrCS1Os/Ek5kyh; 24:aqw/gHQ6/JXVBlgLMTKi7V8J/hcCjyV2XjFg/kPLpYbeoWXsKAcEJzLom54RDkwHoDSOidhPOikVXYniiVQG2AJIcTNwjdAJY7TQmbHsKYw=; 7:JZgvV3i5zXZKOFcixxNCGVu4mGfMRe4yzrGuHpMRE/s05QENmGF0c7v9+YVRnxgD4crpfawW+lQ2ocqhOKsbBWXXZOHQsKRFukITZVwndcwWsQ1AUuW1mhBXl/DYHBsD2U5RWQE3H839c26IWMIIwyV+zdBe8oHV8yaiF5bCjWmH7NKR89JhnG3ksn2KRj1CPDL628MNzG89dZNSvzGRszrcNyaWKkeLNBbfFeUvrPo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; 
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(93886004)(92566002)(81166005)(66066001)(19580405001)(5008740100001)(9686002)(19580395003)(5004730100002)(10400500002)(86362001)(87936001)(11100500001)(5002640100001)(106116001)(99286002)(33656002)(5003600100002)(74316001)(76176999)(54356999)(50986999)(3660700001)(4326007)(102836003)(230783001)(6116002)(122556002)(586003)(2900100001)(1720100001)(77096005)(15975445007)(2950100001)(1220700001)(3280700002)(189998001)(110136002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 19:47:53.1605 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 19:47:59 -0000

Hi Juergen

I'm not sure I can share a LWM2M definition files since peoples need fill a=
 form to get access to them, see the following link.

http://technical.openmobilealliance.org/Technical/technical-information/rel=
ease-program/current-releases/oma-lightweightm2m-v1-0

I didn't go through a formal mapping between these two modeling languages b=
ut following is what this mapping might look like:

LWM2M                | YANG
---------------------+---------------
             | module
               | module name
       | description
  | list if true, container if false
          | mandatory
               | leaf if  is true, leaf-list if fa=
lse
               | leaf name
         | config
  | See 
          | mandatory
               | type
   | range or enum
              | units
        | description

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: April-21-16 1:48 PM
To: Michel Veillette 
Cc: Hannes Tschofenig ; core@ietf.org WG 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping=
-00

On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
>=20
> First, LWM2M have its own modeling language encoded in xml.
> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundament=
ally different than something than can be named security.yang.
> A simple xml transform can probably do the conversion between the two wit=
hout any lost.
> LWM2M just have a simpler (subset) modeling language.
>

These are pretty bold statements. Claiming something is simple and knowing =
something is simple are sometimes different things. Have you worked through=
t the details? Is there a decent public definition of the 'simpler (subset)=
 modeling language'? And with public I mean public, not hidden behind all s=
orts of registration walls.

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Apr 21 13:02:19 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308D12E766 for ; Thu, 21 Apr 2016 13:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 (1024-bit key) header.d=trilliant.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw0HUWP-6YLR for ; Thu, 21 Apr 2016 13:02:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0118.outbound.protection.outlook.com [65.55.169.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C1D12E451 for ; Thu, 21 Apr 2016 13:02:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IjCthKgHa9FujzI3cToCXMEeD8RwuV2ueUghWwI9tSw=; b=ha6unngYjViGwapAWE1shDSar7taKZteGwhEYv6StaSVc1maC4xulUldaB9yBUpfiL7p2nwGgG/lCJpGX/EZb3xIBILiBL81KotHXX3Gyz10Y+PcqyZjc9PhphIAk60S/s0hcH56pLYnxOr8jzDT6uVBnGNUlVa+XLuRZVMCfpw=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 20:02:04 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 20:02:04 +0000
From: Michel Veillette 
To: "paduffy@cisco.com" , "core@ietf.org" 
Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmVpbGxldHRlLWNv?= =?utf-8?Q?re-yang-cbor-mapping-00?=
Thread-Index: AQHRkyOt8k0bOhfeX0GvA3ed8jYnhJ+UPhMAgACTYYCAABh5sA==
Date: Thu, 21 Apr 2016 20:02:04 +0000
Message-ID: 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net> <57191C3F.6030004@cisco.com>
In-Reply-To: <57191C3F.6030004@cisco.com>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: cisco.com; dkim=none (message not signed) header.d=none; cisco.com; dmarc=none action=none header.from=trilliantinc.com; 
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: 0620ea37-a939-40c0-ff4c-08d36a1fcf44
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:2ddwFCJSUe9PD4JMEhB2YdgIlSWIZboqNp9XQ79AzJRoKX4WHjKz5199U7ajKE5TNo4KLXqa26cj6R9eZDf3LGt14Ba2MBNQ4OnwXyoOXo8mRPessW1RvUMuqGrW/LeIxnpg+WTkxNoMklyrlGUKncJ5tN33XsfEga2WEHcy87APb7j59NzVZXtNrKLYuHBZ; 24:f07GAOGcmE2YSjb7VnAcFKGhkaVfjNcsvIJQAEeUwuElW7Ts/VCxMhmjDO4c7w8ps0zybmpHHLYlblWujIyBcDDnc0U1H6hIblTGg+UpLKo=; 7:OTfov3zjicGMynhf9yE0Xw+nP/PjG4CY/Yw+si9BRJ+I1PvXjf8OaGmU9ekMF/Y8DVaD5iAdXL6vNU1UrsxNmEmfpixbj4eQoKdPmQwh4ERXKoI3f8AfJnAtJo7UA1E9mhnzhhmvqKgdJnXOTUuSPIWPLwwUiduuLmG98QPSjLno6lqKSZWVLSuUeYY+yEzmUVRVUOgSQdbRPgI/KOLs7B5OBFzqIMDHxg1jv/DvFpI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; 
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(24454002)(377454003)(54356999)(86362001)(66066001)(19617315012)(87936001)(50986999)(15395725005)(76176999)(74316001)(230783001)(33656002)(122556002)(19625215002)(106116001)(229383001)(99286002)(189998001)(77096005)(16236675004)(790700001)(3660700001)(19300405004)(5008740100001)(3280700002)(6116002)(15975445007)(76576001)(102836003)(586003)(2950100001)(5002640100001)(1220700001)(5004730100002)(2501003)(19580395003)(9686002)(19580405001)(10400500002)(92566002)(81166005)(11100500001)(5003600100002)(2900100001)(5001770100001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1763FBD6CA5713264555DBDEFE6E0BLUPR06MB1763namp_"
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 20:02:04.0625 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761
Archived-At: 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 20:02:18 -0000

--_000_BLUPR06MB1763FBD6CA5713264555DBDEFE6E0BLUPR06MB1763namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUGF1bA0KDQpUaGUgd29ya2luZyBkb2N1bWVudHMgYXJlIGF2YWlsYWJsZSBhdCBodHRwOi8v
Y29yZS13Zy5naXRodWIuaW8veWFuZy1jYm9yLw0KLnlhbmcgYW5kIC5zaWQgZmlsZSBleGFtcGxl
cyBhcmUgYXZhaWxhYmxlIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3lhbmctY2Jvci90
cmVlL21hc3Rlci9yZWdpc3RyeQ0KDQpGb3IgdGhlIHJ1bm5pbmcgY29kZSwgeW91IHdpbGwgaGF2
ZSB0byB3YWl0IGFyb3VuZCB0aGUgbmV4dCBJRVRGLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZy
b206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVs
IER1ZmZ5DQpTZW50OiBBcHJpbC0yMS0xNiAyOjMwIFBNDQpUbzogY29yZUBpZXRmLm9yZw0KU3Vi
amVjdDogUmU6IFtjb3JlXSDwn5SUIFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXZlaWxsZXR0ZS1jb3Jl
LXlhbmctY2Jvci1tYXBwaW5nLTAwDQoNClRoYW5rcyBIYW5uZXMNCg0KQSBmZXcgcmVsYXRlZCBj
b21tZW50cy4uLi4NCg0KcmU6IDIgYW5kIDMuICBJIGRvIHNlZSBhIG1hY2hpbmUgY29uc3VtYWJs
ZSBpbnRlcmZhY2UgLyByZXNvdXJjZSBkZWZpbml0aW9uIGFzIHVzZWZ1bC4gIEF0IGxlYXN0IGFz
IHRoZSBjb250cmFjdCBib3RoIGVuZHMgb2YgdGhlIGNvbW11bmljYXRpb24gd2lsbCBjb2RlLiAg
UmVjZW50IENpc2NvIGV4cGVyaWVuY2UgdW5kZXJsaW5lcyBjby1kZXZlbG9waW5nIHVzaW5nIHBy
b3NlIGJhc2VkIGRlc2NyaXB0aW9ucyBpcyBoaWdobHkgZXJyb3IgcHJvbmUgKEkgbm90IHN1cnBy
aXNlZCkuICBJJ20gZnVydGhlciBhbiBhZHZvY2F0ZSBvZiB1c2luZyB0aGVzZSBpbnRlcmZhY2Ug
ZGVzY3JpcHRpb25zIGZvciBjb2RlIGdlbiwgZG9jIGdlbiwgYW5kIGNvbmZvcm1hbmNlIHRlc3Rp
bmcgdG9vbHMgKHdoZW4gY2VydGlmaWNhdGlvbiBpcyBiZWluZyBwZXJmb3JtZWQpLiAgVGhlIHBy
byBJREwgbWFjcm8gcG9pbnRzIGhhdmUgbm90IGNoYW5nZWQgb3ZlciB0aGUgeWVhcnM6IENvcmJh
LCBDT00sIFdTREwsIFdBREwsIGFuZCBub3cgdGhlIElvVCBzcGFjZS4NCg0KcmU6IDQuICBUaGlz
IGlzIGEgdG91Z2ggb25lLiAgSSBzdHJ1Z2dsZSB3aXRoIFlBTkcgZm9yIElvVC4gIEFja25vd2xl
ZGdpbmcgaXQgaXMgdGhlIElFVEYncyBiYWJ5LiAgQnV0IEkgc2VlIG5vIHRyYWN0aW9uIG91dCBh
dCB0aGUgZmFyIGVkZ2Ugb2YgSW9ULiAgIERpZmZlcmVudCBkaWFsZWN0cz8gIFRvb2xpbmcgc3Vw
cG9ydCAoZWRpdG9ycywgdmFsaWRhdG9ycywgY29kZSBnZW4sIGRvYyBnZW4sIGV0Yyk/IENpc2Nv
IGlzIHB1dHRpbmcgZWZmb3J0IGludG8gdGhlIFJBTUwgZWNvc3lzdGVtLCBPQ0YgYmVpbmcgYSBm
aXJzdCBleGFtcGxlIG9mIHRoYXQuDQoNCmh0dHA6Ly93d3cub25laW90YS5vcmcvZG9jdW1lbnRz
P2ZpbHRlclttZWRpYV90eXBlXT1hcHBsaWNhdGlvbiUyRnJhbWwlMkJ5YW1sDQoNCkkgYmV0dGVy
IHVuZGVyc3RhbmQgUkFNTCwgYnV0IGFtIGhhcHB5IHRvIGJlIGVubGlnaHRlbmVkIHJlOiBZQU5H
IGZvciBJb1QgZW5kcG9pbnRzLiAgRG9lcyBhbnlvbmUgaGF2ZSBhIHNpZGUgYnkgc2lkZSBleGFt
cGxlIHdvcmtlZCBvdXQ/ICBJbnRlcmZhY2UgZGVmaW5pdGlvbiB0byBydW5uaW5nIGNvZGU/DQoN
CkNoZWVycw0KDQoNCk9uIDQvMjEvMjAxNiA1OjQyIEFNLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90
ZToNCg0KSGkgQ2Fyc3RlbiwgSGkgYWxsLA0KDQoNCg0KSSB0aGluayB3ZSBhcmUgZ29pbmcgdG8g
ZmFzdCBoZXJlLg0KDQoNCg0KV2UgaGFyZGx5IG1ha2UgYW55IHByb2dyZXNzIHdpdGggdGhlIGV4
aXN0aW5nIFdHIGl0ZW1zIGJ1dCB0aGVuIHdlIGFkZCBhDQoNCm51bWJlciBvZiBuZXcgaXRlbXMg
dGhhdCBhcmUgYmFyZWx5IHVuZGVyc3Rvb2QuDQoNCg0KDQpUaGlzIGNhbGwgZm9yIGFkb3B0aW9u
IGlzIG5vdCBhIGNhbGwgZm9yIHRoaXMgZG9jdW1lbnQgdGhpcyBpcyBhDQoNCnF1ZXN0aW9uIHdo
ZXRoZXIgd2Ugd2FudCB0byB3b3JrIG9uIHRoZSBmb2xsb3dpbmcgdHdvIHR5cGVzIG9mIHRoaW5n
czoNCg0KDQoNCmEpIGEgZGF0YSBtb2RlbGxpbmcgbGFuZ3VhZ2UgKFlhbmcpIGZvciB1c2Ugd2l0
aCBJb1Qgb2JqZWN0cyAod2hpY2ggaW4NCg0KY2FzZSBvZiBJb1QgYXJlIGxhcmdlbHkgZGVmaW5l
ZCBlbHNld2hlcmUpLCBhbmQNCg0KDQoNCmIpIHJlLXVzZSBhIHByb3RvY29sIG1hY2hpbmVyeSBv
cmlnaW5hbGx5IGRlZmluZWQgZm9yIG5ldHdvcmsgbWFuYWdlbWVudA0KDQphcm91bmQgTmV0Y29u
ZiAod2hpY2ggbWF5IG5vdyBiZSBjb252ZXJ0ZWQgdG8gQ29BUCBhbmQgQ0JPUiB1c2FnZSkuDQoN
Cg0KDQpJIGhhdmUgc3BlbnQgc29tZSB0aW1lIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQgdGhl
IGltcGxpY2F0aW9ucyBhcmUNCg0KYW5kICh0aGF0J3MgYSBib2xkIHN0YXRlbWVudCkgZG91YnQg
dGhhdCBtb3N0IFdHIHBhcnRpY2lwYW50cyAoZXhjZXB0DQoNCmZvciB0aGUgYXV0aG9ycyBvZiB0
aGUgZG9jdW1lbnRzKSByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IHRoaXMgcmVhbGx5IG1lYW5zLg0K
DQoNCg0KSGVyZSBhcmUgdGhlIGNsYWltczoNCg0KDQoNCjEpIElvVCB3aWxsIHJlLXVzZSBtYW55
IG9mIHRoZSBvYmplY3RzIGRlZmluZWQgZm9yIG5ldHdvcmsgbWFuYWdlbWVudC4NCg0KDQoNCjIp
IFRoZXJlIGlzIGEgbmVlZCBmb3IgYSBmb3JtYWwgbGFuZ3VhZ2UgdG8gZGVzY3JpYmUgdGhlIGRh
dGEgbW9kZWwuDQoNCg0KDQozKSBUaGVyZSBpcyBhIHZhbHVlIGluIGdlbmVyYXRpbmcgY29kZSB1
c2luZyB0aGF0IGZvcm1hbCBkYXRhIG1vZGVsDQoNCmRlc2NyaXB0aW9uLg0KDQoNCg0KNCkgWWFu
ZyAoYXMgYSBkYXRhIG1vZGVsbGluZyBsYW5ndWFnZSkgYW5kIHRoZSByZWxhdGVkIHByb3RvY29s
cyBhcmUgYQ0KDQpnb29kIG1hdGNoIGZvciB0aGUgcmVxdWlyZW1lbnRzIHBlb3BsZSBoYXZlLg0K
DQoNCg0KQXJlIHRoZXNlIGNsYWltcyBhY3R1YWxseSB0cnVlPw0KDQoNCg0KR2l2ZW4gdGhhdCB3
ZSBhcmUgbGF0ZSBhdCB0aGUgcGFydHkgYW5kIG90aGVyIG9yZ2FuaXphdGlvbnMgaGF2ZSBkb25l
IGENCg0KZmFpciBhbW91bnQgb2Ygd29yayBpbiB0aGF0IHNwYWNlIGFscmVhZHkgSSBhbSB3b25k
ZXJpbmcgd2hldGhlciB3ZSBoYXZlDQoNCmRvbmUgb3VyIGhvbWUgd29yayBvZiBhbmFseXNpcyB0
aGUgZXhpc3RpbmcgbGFuZHNjYXBlIG9yIHdoZXRoZXIgd2UgYXJlDQoNCmp1c3QgaW50ZXJlc3Rl
ZCB0byBhZGQgYW5vdGhlciBzZXQgb2Ygc3RhbmRhcmRzIHRvIHRoZSBtaXguDQoNCg0KDQpJIGhh
dmUgbXkgb3BpbmlvbiBhYm91dCB0aGUgY2xhaW1zIGFuZCBJIHdvdWxkIGxpa2UgdG8gc2hhcmUg
dGhlbSB3aXRoIHlvdS4NCg0KDQoNClJlZ2FyZGluZyAoMSkgb24gdGhlIHJlLXVzZSBhcmd1bWVu
dC4gSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHRoZQ0KDQpleGlzdGluZywgYWxyZWFkeSBzdGFuZGFy
ZGl6ZWQgb2JqZWN0cyBkZWZpbmVkIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQNCg0KYXJlIGEgZ29v
ZCBmaXQgZm9yIHdoYXQgd2UgYXJlIGRvaW5nIGluIElvVC4gSSBoYXZlIG5vdCBzZWVuIHRoZQ0K
DQpleGFtcGxlcyB3aGVyZSB0aGVyZSBpcyByZS11c2UuIEFzIGlsbHVzdHJhdGVkIGJlbG93LCBJ
IGFtIGV4cG9zaW5nIG15DQoNCnNlbnNvcnMsIGJ1dHRvbnMsIGFuZCBMRURzIHRvIG91dHNpZGUg
d29ybGQgcmF0aGVyIHRoYW4gbmV0d29yaw0KDQppbnRlcmZhY2VzIGFuZCBhbGlrZS4gSSBmdWxs
eSB1bmRlcnN0YW5kIHRoYXQgdGhlIHdvcmxkIGlzIGZhciBtb3JlDQoNCmNvbXBsZXggd2l0aCBy
b3V0ZXJzIGFuZCBzd2l0Y2hlcyB0aGF0IGhhdmUgbWFueSBwb3J0cyBhbmQgbG90cyBvZg0KDQpj
b25maWd1cmF0aW9uIHBhcmFtZXRlcnMuIFRoZXkgYXJlIGFsc28gcnVubmluZyByZWd1bGFyIG9w
ZXJhdGluZw0KDQpzeXN0ZW1zLCBsaWtlIExpbnV4Lg0KDQoNCg0KUmVnYXJkaW5nICgyKSBvbiB0
aGUgdXNlIG9mIGZvcm1hbCBsYW5ndWFnZXMuIEl0IHNlZW1zIHRoYXQgbW9zdA0KDQpvcmdhbml6
YXRpb25zIGFyZSB1c2luZyBmb3JtYWwgbGFuZ3VhZ2VzIGZvciBkZXNjcmliaW5nIHRoZWlyIG9i
amVjdA0KDQpkZWZpbml0aW9ucyBhbHJlYWR5IHRvZGF5LiBJIHBlcnNvbmFsbHkgYmVsaWV2ZSB0
aGF0IHRoZXNlIGZvcm1hbA0KDQpsYW5ndWFnZXMgZG8gbm90IHByb3ZpZGUgYSBsb3Qgb2YgdmFs
dWUgaW4gZ2VuZXJhbCBidXQgdXNpbmcgc29tZXRoaW5nDQoNCnRoYXQgaXMgZWFzeSBmb3IgaHVt
YW5zIHRvIHdyaXRlIGFuZCByZWFkIGlzIHNvbWV0aGluZyBJIG1heSBiZSBPSyB3aXRoLg0KDQpQ
YXJ0aWN1bGFybHkgdGhlIGV4YW1wbGUgYmVsb3cgc2hvd3MgdGhhdCBhbGwgSSBuZWVkIGFzIGEg
ZGV2ZWxvcGVyIGlzDQoNCnZlcnkgbGl0dGxlLiBJb1QgZGV2aWNlcyB0eXBpY2FsbHkgZG8gbm90
IGhhdmUgbWFueSBzZW5zb3JzIGFuZCB0aGUNCg0KaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBp
cyBlbHNld2hlcmUgKHdpdGggdGhlIG9wZXJhdGluZyBzeXN0ZW0sIHRoZQ0KDQp0b29sIGNoYWlu
LCBhbmQgdmFyaW91cyBsb3cgcG93ZXIgc2V0dGluZ3MpLg0KDQoNCg0KUmVnYXJkaW5nICgzKSBv
biB0aGUgdmFsdWUgb2YgY29kZSBnZW5lcmF0aW9uLg0KDQoNCg0KSSBhbSBjdXJyZW50bHkgaW4g
dGhlIHByb2Nlc3Mgb2Ygd3JpdGluZyBhIG5ldyB0dXRvcmlhbCBmb3IgYSBkZXZlbG9wZXINCg0K
d29ya3Nob3AgaG9zdGVkIGJ5IHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5jZSAoT01BKSwgc2VlDQoN
Cmh0dHA6Ly9vcGVubW9iaWxlYWxsaWFuY2Uub3JnL2ZyZWUtaGFuZHMtb24tdHJhaW5pbmctZm9y
LWlvdC1kZXZlbG9wZXJzLXdpdGgtb21hLWx3bTJtLWFuZC1hcm0tYmFzZWQtbWljcm9wcm9jZXNz
b3JzLw0KDQoNCg0KSSBhbSB1c2luZyByZWd1bGFyIElvVCBoYXJkd2FyZSwgbmFtZWx5IHRoZSBL
NjRGIGJvYXJkIHdpdGggb25ib2FyZA0KDQpzZW5zb3JzLCBuYW1lbHkgYW4gYWNjZWxlcm9tZXRl
ciBhbmQgbWFnbmV0b21ldGVyLCBhbiBSR0IgTEVELCBhbmQgdHdvDQoNCmJ1dHRvbnMuIFRoZSBz
ZW5zb3JzIGFyZSBjb25uZWN0ZWQgdXNpbmcgSTJDIGFuZCBhcmUgY2VydGFpbmx5IG5vdCBhbW9u
Zw0KDQp0aGUgbW9zdCBzaW1wbGlzdGljICh3aGljaCB0aGUgZGF0YSBzaGVldCBvZiBhbG1vc3Qg
MTAwIHBhZ2VzIGNhbiBlYXNpbHkNCg0KdGVsbCB5b3UpLg0KDQoNCg0KSW4gdGhlIHByb2Nlc3Mg
b2Ygd3JpdGluZyBjb2RlIEkgbmVlZCB0byBkbyB0aGUgZm9sbG93aW5nOg0KDQoNCg0KKiBGaWd1
cmUgb3V0IGhvdyB0byBjb25uZWN0IHRvIHRoZSBzZW5zb3JzIHVzaW5nIEkyQy4NCg0KDQoNCiog
TGVhcm4gaG93IHRoZSBzZW5zb3Igd29ya3MsIGhvdyB0byBjb25maWd1cmUgdGhlIHNlbnNvciB0
byBkbyB3aGF0IEkNCg0Kd2FudCwgYW5kIHRvIGNvbnZlcnQgdGhlIHJhdyBzZW5zb3IgZGF0YSBp
bnRvIHNvbWV0aGluZyBzdWl0YWJsZSBmb3IgbXkNCg0KYXBwbGljYXRpb24uIE9uZSBjYW4gb25s
eSBob3BlIHRvIGZpbmQgYSBsaWJyYXJ5IHRoYXQgZG9lcyB0aGVzZSB0aGluZ3MNCg0KYWxyZWFk
eSBhbmQgdG8gb25seSBoYXZlIHRvIGFkanVzdCB0aGUgc2V0dGluZ3MgcmF0aGVyIHRoYW4gd3Jp
dGluZw0KDQpldmVyeXRoaW5nIGZyb20gc2NyYXRjaC4gVGhhdCB0eXBpY2FsbHkgdGFrZXMgYSBs
b3Qgb2YgdGltZS4NCg0KDQoNCiogRGV0ZXJtaW5lIHdoZXRoZXIgaXMgYSBzdWl0YWJsZSBvYmpl
Y3QgZGVmaW5pdGlvbiBhbHJlYWR5IGF2YWlsYWJsZS4NCg0KSW4gbXkgY2FzZSBJIGFtIGxvb2tp
bmcgYXQgdGhlIE9NTkEgcmVnaXN0cnkgKHdoaWNoIGhhcyBhbHNvIGJlZW4NCg0KcG9wdWxhdGVk
IHdpdGggdGhlIG9iamVjdHMgZnJvbSB0aGUgSVBTTyBBbGxpYW5jZSkuIEhlcmUgYXJlIHRoZQ0K
DQpyZWdpc3RlcmVkIG9iamVjdHM6DQoNCmh0dHA6Ly90ZWNobmljYWwub3Blbm1vYmlsZWFsbGlh
bmNlLm9yZy9UZWNobmljYWwvdGVjaG5pY2FsLWluZm9ybWF0aW9uL29tbmEvbGlnaHR3ZWlnaHQt
bTJtLWx3bTJtLW9iamVjdC1yZWdpc3RyeQ0KDQoNCg0KSW4gY2FzZSBvZiB0aGUgQWNjZWxlcm9t
ZXRlciBhbmQgdGhlIE1hZ25ldG9tZXRlciBJIGFtIGx1Y2t5IHNpbmNlIHRob3NlDQoNCmhhdmUg
YWxyZWFkeSBiZWVuIGRlZmluZWQuIEkgZG9uJ3QgbmVlZCB0byBkZWZpbmUgbXkgb3duIG9iamVj
dHMsIHdoaWNoDQoNCmlzIGEgc2ltcGxlIHRhc2sgZ2l2ZW4gdGhlIG5ldyBPTUEgb2JqZWN0IGVk
aXRvcg0KDQpodHRwOi8vZGV2dG9vbGtpdC5vcGVubW9iaWxlYWxsaWFuY2Uub3JnL09FZGl0b3Iv
RGVmYXVsdA0KDQoNCg0KKiBUaGVuLCBJIG5lZWQgdG8gYWRkIHRoZSBjb2RlIGZvciB1c2Ugd2l0
aCB0aGVtLiBIZXJlIGlzIHdoZXJlIHRoZQ0KDQpmb3JtYWwgZGVzY3JpcHRpb24gb2YgdGhlIGRh
dGEgbW9kZWwgY291bGQgaGVscCBtZSB0byBhdXRvbWF0aWNhbGx5DQoNCnByb2R1Y2UgY29kZS4N
Cg0KDQoNCk5vdywgdGhpcyBpcyB0aGUgZnVubnkgdGhpbmc6IHRoaXMgY29kZSBhbW91bnRzIGZv
ciBhcm91bmQgNSBsaW5lcywNCg0KZGVwZW5kaW5nIG9uIHRoZSBBUEkgYW5kIHByb2dyYW1taW5n
IGxhbmd1YWdlIHlvdSBhcmUgdXNpbmcuIE1vc3QgbGlrZWx5DQoNCnRoZSBjb2RlIGdlbmVyYXRp
b24gd2lsbCBwcm9kdWNlIHNvbWUgY29kZSB0aGF0IHlvdSBjYW5ub3QgZGlyZWN0bHkgdXNlLg0K
DQoNCg0KSGVyZSBpcyB3aGF0IEkgaGF2ZSB0byB3cml0ZSBvbiB0aGUgSW9UIHNpZGU6DQoNCg0K
DQotLS0tDQoNCg0KDQovLyBDcmVhdGUgb2JqZWN0ICczMzEzJyA9ICdBY2NlbGVyb21ldGVyJw0K
DQphY2Nfb2JqZWN0ID0gTTJNSW50ZXJmYWNlRmFjdG9yeTo6Y3JlYXRlX29iamVjdCgiMzMxMyIp
Ow0KDQoNCg0KTTJNT2JqZWN0SW5zdGFuY2UqIGFjY19pbnN0ID0gYWNjX29iamVjdC0+Y3JlYXRl
X29iamVjdF9pbnN0YW5jZSgpOw0KDQoNCg0KTTJNUmVzb3VyY2UqIGFjY194X3JlcyA9IGFjY19p
bnN0LT5jcmVhdGVfZHluYW1pY19yZXNvdXJjZSgiNTcwMiIsICJYDQoNClZhbHVlIixNMk1SZXNv
dXJjZUluc3RhbmNlOjpGTE9BVCwgdHJ1ZSAvKiBvYnNlcnZhYmxlICovKTsNCg0KDQoNCk0yTVJl
c291cmNlKiBhY2NfeV9yZXMgPSBhY2NfaW5zdC0+Y3JlYXRlX2R5bmFtaWNfcmVzb3VyY2UoIjU3
MDMiLCAiWQ0KDQpWYWx1ZSIsTTJNUmVzb3VyY2VJbnN0YW5jZTo6RkxPQVQsIHRydWUgLyogb2Jz
ZXJ2YWJsZSAqLyk7DQoNCg0KDQpNMk1SZXNvdXJjZSogYWNjX3pfcmVzID0gYWNjX2luc3QtPmNy
ZWF0ZV9keW5hbWljX3Jlc291cmNlKCI1NzA0IiwgIloNCg0KVmFsdWUiLE0yTVJlc291cmNlSW5z
dGFuY2U6OkZMT0FULCB0cnVlIC8qIG9ic2VydmFibGUgKi8pOw0KDQoNCg0KLS0tLS0NCg0KDQoN
CkkgZmVhciB0aGF0IHdlIGFyZSBvcHRpbWl6aW5nIGZvciBzb21ldGhpbmcgdGhhdCBkb2VzIG5v
dCB0YWtlIGEgbG9uZw0KDQp0aW1lIGFueXdheS4gSXQgd2lsbCB0YWtlIGxvbmdlciB0byBmZXRj
aCB0aGUgcmVsZXZhbnQgWWFuZyBmaWxlLCB0byB1c2UNCg0KdGhlIHRvb2xzIHRvIGdlbmVyYXRl
IHRoZSBjb2RlIGFuZCB0byBpbnRlZ3JhdGUgaXQgaW50byB0aGUgZXhpc3RpbmcNCg0KY29kZSB0
aGFuIHRvIGp1c3Qgd3JpdGUgdGhlc2UgZmV3IGxpbmVzIHlvdXJzZWxmLg0KDQoNCg0KV2hhdCB0
aGUgYWJvdmUgZXhhbXBsZSBkb2VzIG5vdCB1dGlsaXplIHBvdGVudGlhbCBjb2RlIGdlbmVyYXRp
b24gZm9yDQoNCnRoZSBhY3R1YWwgaW50ZXJhY3Rpb24gbW9kZWwuIEluIG15IGNhc2UgbXkgY29k
ZSBpcyBoYXJkLXdpcmVkIHRvIHVzZQ0KDQpMV00yTS4NCg0KDQoNClNpbmNlIEkgaGF2ZSBub3Qg
eWV0IHNlZW4gYSBtZWFuaW5nZnVsIGV4YW1wbGUgb2YgWWFuZyBmb3IgdGhlIElvVA0KDQplbnZp
cm9ubWVudCBJIGFsc28gaGF2ZW4ndCBzZWVuIG9uZSB0aGF0IHByb2R1Y2VzIG1lYW5pbmdmdWwg
Y29kZSBmb3INCg0KdGhlIGludGVyYWN0aW9uIG1vZGVsIGVpdGhlci4NCg0KDQoNClJlZ2FyZGlu
ZyAoNCkgY29uY2VybmluZyBZYW5nIGFzIGEgZGF0YSBtb2RlbGxpbmcgbGFuZ3VhZ2UgKHZzLiBv
dGhlcg0KDQpsYW5ndWFnZXMgYWxzbyBjb25zaWRlcmVkIGJ5IHRoZSBJb1QgY29tbXVuaXRpZXMp
LiBBcyBQYXVsIG5vdGVkIHRoZXJlDQoNCmFyZSBvdGhlciBsYW5ndWFnZXMgaW4gdG93biBhbmQg
SSBwZXJzb25hbGx5IGRvIG5vdCBrbm93IHdoZXRoZXIgdGhlDQoNCmZlYXR1cmVzIG9mZmVyZWQg
YnkgWWFuZyBhcmUgYmV0dGVyIG9yIGVxdWFsIHRvIHRob3NlIG9mZmVyZWQgYnkgdGhlDQoNCm90
aGVyIGxhbmd1YWdlcy4gSSBjZXJ0YWlubHkgaGF2ZW4ndCBkb25lIHRoYXQgYW5hbHlzaXMuDQoN
Cg0KDQpBcyBhIGNvbmNsdWRpbmcgcmVtYXJrIEkgd291bGQgbGlrZSB0byBzYXkgdGhhdCB3aGls
ZSBteSBjdXJyZW50DQoNCmFzc2Vzc21lbnQgbWF5IHNvdW5kIG5lZ2F0aXZlIEkgYW0gaGFwcHkg
dG8gbGVhcm4gbW9yZSBhYm91dCB0aGlzIHRvcGljDQoNCmFuZCBtaWdodCBnZXQgY29udmluY2Vk
IHRoYXQgWWFuZyBpcyB0aGUgcmlnaHQgdG9vbC4gQ3VycmVudGx5LCBJIGp1c3QNCg0KaGF2ZW4n
dCByZWFjaGVkIHRoYXQgbGV2ZWwgeWV0IGFuZCBJIGNhbiBjbGFpbSB0aGF0IEkgaGF2ZSBzcGVu
dCBzb21lDQoNCnRpbWUgbG9va2luZyBhdCB0aGlzIHRvcGljIGFscmVhZHkuDQoNCg0KDQpDaWFv
DQoNCkhhbm5lcw0KDQoNCg0KDQoNCk9uIDA0LzEwLzIwMTYgMDI6MjIgUE0sIENhcnN0ZW4gQm9y
bWFubiB3cm90ZToNCg0KSW4gQnVlbm9zIEFpcmVzLCB3ZSBkaXNjdXNzZWQgdGhlIGFkb3B0aW9u
IG9mDQoNCmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1tYXBwaW5nLTAwIGJ1dCBub3Qg
ZW5vdWdoIHBlb3BsZSBoYWQgcmVhZA0KDQp0aGUgZG9jdW1lbnQgdG8gZ28gZm9yIGFuIGluLXJv
b20gY29uc2Vuc3VzIGNhbGwuDQoNCg0KDQpUaGlzIGlzIGEgdHdvLXdlZWsgY2FsbCBmb3IgYWRv
cHRpb24gb2YNCg0KZHJhZnQtdmVpbGxldHRlLWNvcmUteWFuZy1jYm9yLW1hcHBpbmctMDAgYXMg
YSBXRyBkb2N1bWVudCBvZiBDb1JFLg0KDQpTcGVjaWZpY2FsbHksIGlmIHlvdSAoMSkgc3VwcG9y
dCBvciAoMikgaGF2ZSBhbiBvYmplY3Rpb24gdG8gdGhpcw0KDQpkZWNpc2lvbiwgcGxlYXNlIHNw
ZWFrIHVwIG9uIHRoZSBtYWlsaW5nIGxpc3QgYnkgMjAxNi0wNC0yNC4NCg0KDQoNCk5vdGUgdGhh
dCB0aGlzIHdvcmsgaXMgZXhwbGljaXRseSBjb3ZlcmVkIGJ5IG91ciBjaGFydGVyLCBzbyBkaXNj
dXNzaW9ucw0KDQpvZiB3aGljaCBXRyBzaG91bGQgd29yayBvbiB0aGlzIGFyZSBvZmYtdG9waWMu
DQoNCg0KDQpBcyBhbHdheXMsIGFkb3B0aW9uIG9mIGEgZG9jdW1lbnQgYXMgYSBXRyBkb2N1bWVu
dCBpcyBub3QgYSB2b3RlIG9uDQoNCndoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFz
dC1jYWxsIHN0YXRlOyB0aGUgaW50ZW50aW9uIGlzIHRvDQoNCndvcmsgb24gdGhlIFdHIGRvY3Vt
ZW50IGFmdGVyIGFkb3B0aW9uIGZvciBhIHdoaWxlIHRvIGdldCBpdCByZWFkeSBmb3INCg0KbGFz
dCBjYWxsLiAgSWYgeW91IHdhbnQgdG8gY29tYmluZSB5b3VyIHN1cHBvcnQvb2JqZWN0aW9uIHdp
dGggdGVjaG5pY2FsDQoNCmNvbW1lbnRzLCB0aGlzIGlzIGNlcnRhaW5seSB3ZWxjb21lIHNvIHdl
IGNhbiBhY2NlbGVyYXRlIHRoYXQgcHJvY2Vzcy4NCg0KDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmNv
cmUgbWFpbGluZyBsaXN0DQoNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQoNCg0KDQoNCg0K
DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmNv
cmUgbWFpbGluZyBsaXN0DQoNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQoN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo=

--_000_BLUPR06MB1763FBD6CA5713264555DBDEFE6E0BLUPR06MB1763namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBT
eW1ib2wiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmlu
aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGku
bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tQ0Ei
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBQYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTIj5UaGUgd29ya2luZyBkb2N1bWVudHMgYXJlIGF2YWlsYWJsZSBhdA0KPGEg
aHJlZj0iaHR0cDovL2NvcmUtd2cuZ2l0aHViLmlvL3lhbmctY2Jvci8iPmh0dHA6Ly9jb3JlLXdn
LmdpdGh1Yi5pby95YW5nLWNib3IvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTIj4ueWFuZyBhbmQgLnNpZCBmaWxlIGV4YW1wbGVzIGFyZSBhdmFpbGFibGUg
YXQNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL3lhbmctY2Jvci90cmVlL21h
c3Rlci9yZWdpc3RyeSI+aHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cveWFuZy1jYm9yL3RyZWUv
bWFzdGVyL3JlZ2lzdHJ5PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj5Gb3IgdGhlIHJ1bm5pbmcgY29kZSwgeW91IHdpbGwgaGF2ZSB0byB3YWl0IGFyb3VuZCB0
aGUgbmV4dCBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVn
YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWljaGVs
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp
bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOndpbmRvd3RleHQiPiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+
T24gQmVoYWxmIE9mIDwvYj5QYXVsIER1ZmZ5PGJyPg0KPGI+U2VudDo8L2I+IEFwcmlsLTIxLTE2
IDI6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtjb3JlXSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOndpbmRvd3RleHQiPiYjMTI4Mjc2Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBXRyBhZG9wdGlvbiBvZiBkcmFmdC12ZWlsbGV0dGUt
Y29yZS15YW5nLWNib3ItbWFwcGluZy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgSGFubmVzPGJyPg0KPGJyPg0KQSBmZXcgcmVs
YXRlZCBjb21tZW50cy4uLi48YnI+DQo8YnI+DQpyZTogMiBhbmQgMy4mbmJzcDsgSSBkbyBzZWUg
YSBtYWNoaW5lIGNvbnN1bWFibGUgaW50ZXJmYWNlIC8gcmVzb3VyY2UgZGVmaW5pdGlvbiBhcyB1
c2VmdWwuJm5ic3A7IEF0IGxlYXN0IGFzIHRoZSBjb250cmFjdCBib3RoIGVuZHMgb2YgdGhlIGNv
bW11bmljYXRpb24gd2lsbCBjb2RlLiZuYnNwOyBSZWNlbnQgQ2lzY28gZXhwZXJpZW5jZSB1bmRl
cmxpbmVzIGNvLWRldmVsb3BpbmcgdXNpbmcgcHJvc2UgYmFzZWQgZGVzY3JpcHRpb25zIGlzIGhp
Z2hseSBlcnJvciBwcm9uZQ0KIChJIG5vdCBzdXJwcmlzZWQpLiZuYnNwOyBJJ20gZnVydGhlciBh
biBhZHZvY2F0ZSBvZiB1c2luZyB0aGVzZSBpbnRlcmZhY2UgZGVzY3JpcHRpb25zIGZvciBjb2Rl
IGdlbiwgZG9jIGdlbiwgYW5kIGNvbmZvcm1hbmNlIHRlc3RpbmcgdG9vbHMgKHdoZW4gY2VydGlm
aWNhdGlvbiBpcyBiZWluZyBwZXJmb3JtZWQpLiZuYnNwOyBUaGUgcHJvIElETCBtYWNybyBwb2lu
dHMgaGF2ZSBub3QgY2hhbmdlZCBvdmVyIHRoZSB5ZWFyczogQ29yYmEsIENPTSwgV1NETCwgV0FE
TCwNCiBhbmQgbm93IHRoZSBJb1Qgc3BhY2UuPGJyPg0KPGJyPg0KcmU6IDQuJm5ic3A7IFRoaXMg
aXMgYSB0b3VnaCBvbmUuJm5ic3A7IEkgc3RydWdnbGUgd2l0aCBZQU5HIGZvciBJb1QuJm5ic3A7
IEFja25vd2xlZGdpbmcgaXQgaXMgdGhlIElFVEYncyBiYWJ5LiZuYnNwOyBCdXQgSSBzZWUgbm8g
dHJhY3Rpb24gb3V0IGF0IHRoZSBmYXIgZWRnZSBvZiBJb1QuJm5ic3A7Jm5ic3A7IERpZmZlcmVu
dCBkaWFsZWN0cz8mbmJzcDsgVG9vbGluZyBzdXBwb3J0IChlZGl0b3JzLCB2YWxpZGF0b3JzLCBj
b2RlIGdlbiwgZG9jIGdlbiwgZXRjKT8gQ2lzY28gaXMgcHV0dGluZyBlZmZvcnQNCiBpbnRvIHRo
ZSBSQU1MIGVjb3N5c3RlbSwgT0NGIGJlaW5nIGEgZmlyc3QgZXhhbXBsZSBvZiB0aGF0LiZuYnNw
OyA8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lm9uZWlvdGEub3JnL2RvY3VtZW50cz9m
aWx0ZXIiPmh0dHA6Ly93d3cub25laW90YS5vcmcvZG9jdW1lbnRzP2ZpbHRlcjwvYT5bbWVkaWFf
dHlwZV09YXBwbGljYXRpb24lMkZyYW1sJTJCeWFtbDxicj4NCjxicj4NCkkgYmV0dGVyIHVuZGVy
c3RhbmQgUkFNTCwgYnV0IGFtIGhhcHB5IHRvIGJlIGVubGlnaHRlbmVkIHJlOiBZQU5HIGZvciBJ
b1QgZW5kcG9pbnRzLiZuYnNwOyBEb2VzIGFueW9uZSBoYXZlIGEgc2lkZSBieSBzaWRlIGV4YW1w
bGUgd29ya2VkIG91dD8mbmJzcDsgSW50ZXJmYWNlIGRlZmluaXRpb24gdG8gcnVubmluZyBjb2Rl
Pzxicj4NCjxicj4NCkNoZWVyczxicj4NCjxicj4NCjxicj4NCk9uIDQvMjEvMjAxNiA1OjQyIEFN
LCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
PkhpIENhcnN0ZW4sIEhpIGFsbCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5JIHRoaW5rIHdlIGFyZSBnb2luZyB0byBmYXN0IGhlcmUuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2UgaGFyZGx5
IG1ha2UgYW55IHByb2dyZXNzIHdpdGggdGhlIGV4aXN0aW5nIFdHIGl0ZW1zIGJ1dCB0aGVuIHdl
IGFkZCBhPG86cD48L286cD48L3ByZT4NCjxwcmU+bnVtYmVyIG9mIG5ldyBpdGVtcyB0aGF0IGFy
ZSBiYXJlbHkgdW5kZXJzdG9vZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5UaGlzIGNhbGwgZm9yIGFkb3B0aW9uIGlzIG5vdCBhIGNhbGwgZm9y
IHRoaXMgZG9jdW1lbnQgdGhpcyBpcyBhPG86cD48L286cD48L3ByZT4NCjxwcmU+cXVlc3Rpb24g
d2hldGhlciB3ZSB3YW50IHRvIHdvcmsgb24gdGhlIGZvbGxvd2luZyB0d28gdHlwZXMgb2YgdGhp
bmdzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PmEpIGEgZGF0YSBtb2RlbGxpbmcgbGFuZ3VhZ2UgKFlhbmcpIGZvciB1c2Ugd2l0aCBJb1Qgb2Jq
ZWN0cyAod2hpY2ggaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jYXNlIG9mIElvVCBhcmUgbGFy
Z2VseSBkZWZpbmVkIGVsc2V3aGVyZSksIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmIpIHJlLXVzZSBhIHByb3RvY29sIG1hY2hpbmVyeSBv
cmlnaW5hbGx5IGRlZmluZWQgZm9yIG5ldHdvcmsgbWFuYWdlbWVudDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmFyb3VuZCBOZXRjb25mICh3aGljaCBtYXkgbm93IGJlIGNvbnZlcnRlZCB0byBDb0FQ
IGFuZCBDQk9SIHVzYWdlKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5JIGhhdmUgc3BlbnQgc29tZSB0aW1lIHRyeWluZyB0byBmaWd1cmUgb3V0
IHdoYXQgdGhlIGltcGxpY2F0aW9ucyBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgKHRo
YXQncyBhIGJvbGQgc3RhdGVtZW50KSBkb3VidCB0aGF0IG1vc3QgV0cgcGFydGljaXBhbnRzIChl
eGNlcHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb3IgdGhlIGF1dGhvcnMgb2YgdGhlIGRvY3Vt
ZW50cykgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB0aGlzIHJlYWxseSBtZWFucy48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5IZXJlIGFyZSB0aGUg
Y2xhaW1zOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPjEpIElvVCB3aWxsIHJlLXVzZSBtYW55IG9mIHRoZSBvYmplY3RzIGRlZmluZWQgZm9yIG5l
dHdvcmsgbWFuYWdlbWVudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4yKSBUaGVyZSBpcyBhIG5lZWQgZm9yIGEgZm9ybWFsIGxhbmd1YWdlIHRv
IGRlc2NyaWJlIHRoZSBkYXRhIG1vZGVsLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMpIFRoZXJlIGlzIGEgdmFsdWUgaW4gZ2VuZXJhdGluZyBj
b2RlIHVzaW5nIHRoYXQgZm9ybWFsIGRhdGEgbW9kZWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5k
ZXNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT40KSBZYW5nIChhcyBhIGRhdGEgbW9kZWxsaW5nIGxhbmd1YWdlKSBhbmQgdGhlIHJl
bGF0ZWQgcHJvdG9jb2xzIGFyZSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Z29vZCBtYXRjaCBm
b3IgdGhlIHJlcXVpcmVtZW50cyBwZW9wbGUgaGF2ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BcmUgdGhlc2UgY2xhaW1zIGFjdHVhbGx5IHRy
dWU/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
R2l2ZW4gdGhhdCB3ZSBhcmUgbGF0ZSBhdCB0aGUgcGFydHkgYW5kIG90aGVyIG9yZ2FuaXphdGlv
bnMgaGF2ZSBkb25lIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mYWlyIGFtb3VudCBvZiB3b3Jr
IGluIHRoYXQgc3BhY2UgYWxyZWFkeSBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHdlIGhhdmU8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5kb25lIG91ciBob21lIHdvcmsgb2YgYW5hbHlzaXMgdGhlIGV4
aXN0aW5nIGxhbmRzY2FwZSBvciB3aGV0aGVyIHdlIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pmp1c3QgaW50ZXJlc3RlZCB0byBhZGQgYW5vdGhlciBzZXQgb2Ygc3RhbmRhcmRzIHRvIHRoZSBt
aXguPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
SSBoYXZlIG15IG9waW5pb24gYWJvdXQgdGhlIGNsYWltcyBhbmQgSSB3b3VsZCBsaWtlIHRvIHNo
YXJlIHRoZW0gd2l0aCB5b3UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+UmVnYXJkaW5nICgxKSBvbiB0aGUgcmUtdXNlIGFyZ3VtZW50LiBJIGRv
IG5vdCBiZWxpZXZlIHRoYXQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhpc3RpbmcsIGFs
cmVhZHkgc3RhbmRhcmRpemVkIG9iamVjdHMgZGVmaW5lZCBmb3IgbmV0d29yayBtYW5hZ2VtZW50
PG86cD48L286cD48L3ByZT4NCjxwcmU+YXJlIGEgZ29vZCBmaXQgZm9yIHdoYXQgd2UgYXJlIGRv
aW5nIGluIElvVC4gSSBoYXZlIG5vdCBzZWVuIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4
YW1wbGVzIHdoZXJlIHRoZXJlIGlzIHJlLXVzZS4gQXMgaWxsdXN0cmF0ZWQgYmVsb3csIEkgYW0g
ZXhwb3NpbmcgbXk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZW5zb3JzLCBidXR0b25zLCBhbmQg
TEVEcyB0byBvdXRzaWRlIHdvcmxkIHJhdGhlciB0aGFuIG5ldHdvcms8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5pbnRlcmZhY2VzIGFuZCBhbGlrZS4gSSBmdWxseSB1bmRlcnN0YW5kIHRoYXQgdGhl
IHdvcmxkIGlzIGZhciBtb3JlPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29tcGxleCB3aXRoIHJv
dXRlcnMgYW5kIHN3aXRjaGVzIHRoYXQgaGF2ZSBtYW55IHBvcnRzIGFuZCBsb3RzIG9mPG86cD48
L286cD48L3ByZT4NCjxwcmU+Y29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiBUaGV5IGFyZSBhbHNv
IHJ1bm5pbmcgcmVndWxhciBvcGVyYXRpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zeXN0ZW1z
LCBsaWtlIExpbnV4LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlJlZ2FyZGluZyAoMikgb24gdGhlIHVzZSBvZiBmb3JtYWwgbGFuZ3VhZ2VzLiBJ
dCBzZWVtcyB0aGF0IG1vc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vcmdhbml6YXRpb25zIGFy
ZSB1c2luZyBmb3JtYWwgbGFuZ3VhZ2VzIGZvciBkZXNjcmliaW5nIHRoZWlyIG9iamVjdDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmRlZmluaXRpb25zIGFscmVhZHkgdG9kYXkuIEkgcGVyc29uYWxs
eSBiZWxpZXZlIHRoYXQgdGhlc2UgZm9ybWFsPG86cD48L286cD48L3ByZT4NCjxwcmU+bGFuZ3Vh
Z2VzIGRvIG5vdCBwcm92aWRlIGEgbG90IG9mIHZhbHVlIGluIGdlbmVyYWwgYnV0IHVzaW5nIHNv
bWV0aGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgaXMgZWFzeSBmb3IgaHVtYW5zIHRv
IHdyaXRlIGFuZCByZWFkIGlzIHNvbWV0aGluZyBJIG1heSBiZSBPSyB3aXRoLjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPlBhcnRpY3VsYXJseSB0aGUgZXhhbXBsZSBiZWxvdyBzaG93cyB0aGF0IGFs
bCBJIG5lZWQgYXMgYSBkZXZlbG9wZXIgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT52ZXJ5IGxp
dHRsZS4gSW9UIGRldmljZXMgdHlwaWNhbGx5IGRvIG5vdCBoYXZlIG1hbnkgc2Vuc29ycyBhbmQg
dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+aW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBpcyBl
bHNld2hlcmUgKHdpdGggdGhlIG9wZXJhdGluZyBzeXN0ZW0sIHRoZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnRvb2wgY2hhaW4sIGFuZCB2YXJpb3VzIGxvdyBwb3dlciBzZXR0aW5ncykuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkaW5n
ICgzKSBvbiB0aGUgdmFsdWUgb2YgY29kZSBnZW5lcmF0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgYW0gY3VycmVudGx5IGluIHRoZSBw
cm9jZXNzIG9mIHdyaXRpbmcgYSBuZXcgdHV0b3JpYWwgZm9yIGEgZGV2ZWxvcGVyPG86cD48L286
cD48L3ByZT4NCjxwcmU+d29ya3Nob3AgaG9zdGVkIGJ5IHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5j
ZSAoT01BKSwgc2VlPG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL29wZW5t
b2JpbGVhbGxpYW5jZS5vcmcvZnJlZS1oYW5kcy1vbi10cmFpbmluZy1mb3ItaW90LWRldmVsb3Bl
cnMtd2l0aC1vbWEtbHdtMm0tYW5kLWFybS1iYXNlZC1taWNyb3Byb2Nlc3NvcnMvIj5odHRwOi8v
b3Blbm1vYmlsZWFsbGlhbmNlLm9yZy9mcmVlLWhhbmRzLW9uLXRyYWluaW5nLWZvci1pb3QtZGV2
ZWxvcGVycy13aXRoLW9tYS1sd20ybS1hbmQtYXJtLWJhc2VkLW1pY3JvcHJvY2Vzc29ycy88L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBh
bSB1c2luZyByZWd1bGFyIElvVCBoYXJkd2FyZSwgbmFtZWx5IHRoZSBLNjRGIGJvYXJkIHdpdGgg
b25ib2FyZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlbnNvcnMsIG5hbWVseSBhbiBhY2NlbGVy
b21ldGVyIGFuZCBtYWduZXRvbWV0ZXIsIGFuIFJHQiBMRUQsIGFuZCB0d288bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5idXR0b25zLiBUaGUgc2Vuc29ycyBhcmUgY29ubmVjdGVkIHVzaW5nIEkyQyBh
bmQgYXJlIGNlcnRhaW5seSBub3QgYW1vbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgbW9z
dCBzaW1wbGlzdGljICh3aGljaCB0aGUgZGF0YSBzaGVldCBvZiBhbG1vc3QgMTAwIHBhZ2VzIGNh
biBlYXNpbHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50ZWxsIHlvdSkuPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SW4gdGhlIHByb2Nlc3Mgb2Yg
d3JpdGluZyBjb2RlIEkgbmVlZCB0byBkbyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiogRmlndXJlIG91dCBob3cgdG8g
Y29ubmVjdCB0byB0aGUgc2Vuc29ycyB1c2luZyBJMkMuPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiBMZWFybiBob3cgdGhlIHNlbnNvciB3b3Jr
cywgaG93IHRvIGNvbmZpZ3VyZSB0aGUgc2Vuc29yIHRvIGRvIHdoYXQgSTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPndhbnQsIGFuZCB0byBjb252ZXJ0IHRoZSByYXcgc2Vuc29yIGRhdGEgaW50byBz
b21ldGhpbmcgc3VpdGFibGUgZm9yIG15PG86cD48L286cD48L3ByZT4NCjxwcmU+YXBwbGljYXRp
b24uIE9uZSBjYW4gb25seSBob3BlIHRvIGZpbmQgYSBsaWJyYXJ5IHRoYXQgZG9lcyB0aGVzZSB0
aGluZ3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbHJlYWR5IGFuZCB0byBvbmx5IGhhdmUgdG8g
YWRqdXN0IHRoZSBzZXR0aW5ncyByYXRoZXIgdGhhbiB3cml0aW5nPG86cD48L286cD48L3ByZT4N
CjxwcmU+ZXZlcnl0aGluZyBmcm9tIHNjcmF0Y2guIFRoYXQgdHlwaWNhbGx5IHRha2VzIGEgbG90
IG9mIHRpbWUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+KiBEZXRlcm1pbmUgd2hldGhlciBpcyBhIHN1aXRhYmxlIG9iamVjdCBkZWZpbml0aW9u
IGFscmVhZHkgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkluIG15IGNhc2UgSSBh
bSBsb29raW5nIGF0IHRoZSBPTU5BIHJlZ2lzdHJ5ICh3aGljaCBoYXMgYWxzbyBiZWVuPG86cD48
L286cD48L3ByZT4NCjxwcmU+cG9wdWxhdGVkIHdpdGggdGhlIG9iamVjdHMgZnJvbSB0aGUgSVBT
TyBBbGxpYW5jZSkuIEhlcmUgYXJlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlZ2lzdGVy
ZWQgb2JqZWN0czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwOi8vdGVjaG5p
Y2FsLm9wZW5tb2JpbGVhbGxpYW5jZS5vcmcvVGVjaG5pY2FsL3RlY2huaWNhbC1pbmZvcm1hdGlv
bi9vbW5hL2xpZ2h0d2VpZ2h0LW0ybS1sd20ybS1vYmplY3QtcmVnaXN0cnkiPmh0dHA6Ly90ZWNo
bmljYWwub3Blbm1vYmlsZWFsbGlhbmNlLm9yZy9UZWNobmljYWwvdGVjaG5pY2FsLWluZm9ybWF0
aW9uL29tbmEvbGlnaHR3ZWlnaHQtbTJtLWx3bTJtLW9iamVjdC1yZWdpc3RyeTwvYT48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBjYXNlIG9m
IHRoZSBBY2NlbGVyb21ldGVyIGFuZCB0aGUgTWFnbmV0b21ldGVyIEkgYW0gbHVja3kgc2luY2Ug
dGhvc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXZlIGFscmVhZHkgYmVlbiBkZWZpbmVkLiBJ
IGRvbid0IG5lZWQgdG8gZGVmaW5lIG15IG93biBvYmplY3RzLCB3aGljaDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmlzIGEgc2ltcGxlIHRhc2sgZ2l2ZW4gdGhlIG5ldyBPTUEgb2JqZWN0IGVkaXRv
cjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHA6Ly9kZXZ0b29sa2l0Lm9wZW5t
b2JpbGVhbGxpYW5jZS5vcmcvT0VkaXRvci9EZWZhdWx0Ij5odHRwOi8vZGV2dG9vbGtpdC5vcGVu
bW9iaWxlYWxsaWFuY2Uub3JnL09FZGl0b3IvRGVmYXVsdDwvYT48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4qIFRoZW4sIEkgbmVlZCB0byBhZGQg
dGhlIGNvZGUgZm9yIHVzZSB3aXRoIHRoZW0uIEhlcmUgaXMgd2hlcmUgdGhlPG86cD48L286cD48
L3ByZT4NCjxwcmU+Zm9ybWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBkYXRhIG1vZGVsIGNvdWxkIGhl
bHAgbWUgdG8gYXV0b21hdGljYWxseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb2R1Y2UgY29k
ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5O
b3csIHRoaXMgaXMgdGhlIGZ1bm55IHRoaW5nOiB0aGlzIGNvZGUgYW1vdW50cyBmb3IgYXJvdW5k
IDUgbGluZXMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGVwZW5kaW5nIG9uIHRoZSBBUEkgYW5k
IHByb2dyYW1taW5nIGxhbmd1YWdlIHlvdSBhcmUgdXNpbmcuIE1vc3QgbGlrZWx5PG86cD48L286
cD48L3ByZT4NCjxwcmU+dGhlIGNvZGUgZ2VuZXJhdGlvbiB3aWxsIHByb2R1Y2Ugc29tZSBjb2Rl
IHRoYXQgeW91IGNhbm5vdCBkaXJlY3RseSB1c2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SGVyZSBpcyB3aGF0IEkgaGF2ZSB0byB3cml0ZSBv
biB0aGUgSW9UIHNpZGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+LS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPi8vIENyZWF0ZSBvYmplY3QgJzMzMTMnID0gJ0FjY2VsZXJvbWV0ZXInPG86
cD48L286cD48L3ByZT4NCjxwcmU+YWNjX29iamVjdCA9IE0yTUludGVyZmFjZUZhY3Rvcnk6OmNy
ZWF0ZV9vYmplY3QoJnF1b3Q7MzMxMyZxdW90Oyk7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TTJNT2JqZWN0SW5zdGFuY2UqIGFjY19pbnN0ID0g
YWNjX29iamVjdC0mZ3Q7Y3JlYXRlX29iamVjdF9pbnN0YW5jZSgpOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk0yTVJlc291cmNlKiBhY2NfeF9y
ZXMgPSBhY2NfaW5zdC0mZ3Q7Y3JlYXRlX2R5bmFtaWNfcmVzb3VyY2UoJnF1b3Q7NTcwMiZxdW90
OywgJnF1b3Q7WDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlZhbHVlJnF1b3Q7LE0yTVJlc291cmNl
SW5zdGFuY2U6OkZMT0FULCB0cnVlIC8qIG9ic2VydmFibGUgKi8pOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk0yTVJlc291cmNlKiBhY2NfeV9y
ZXMgPSBhY2NfaW5zdC0mZ3Q7Y3JlYXRlX2R5bmFtaWNfcmVzb3VyY2UoJnF1b3Q7NTcwMyZxdW90
OywgJnF1b3Q7WTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlZhbHVlJnF1b3Q7LE0yTVJlc291cmNl
SW5zdGFuY2U6OkZMT0FULCB0cnVlIC8qIG9ic2VydmFibGUgKi8pOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk0yTVJlc291cmNlKiBhY2Nfel9y
ZXMgPSBhY2NfaW5zdC0mZ3Q7Y3JlYXRlX2R5bmFtaWNfcmVzb3VyY2UoJnF1b3Q7NTcwNCZxdW90
OywgJnF1b3Q7WjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlZhbHVlJnF1b3Q7LE0yTVJlc291cmNl
SW5zdGFuY2U6OkZMT0FULCB0cnVlIC8qIG9ic2VydmFibGUgKi8pOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBmZWFyIHRoYXQgd2UgYXJl
IG9wdGltaXppbmcgZm9yIHNvbWV0aGluZyB0aGF0IGRvZXMgbm90IHRha2UgYSBsb25nPG86cD48
L286cD48L3ByZT4NCjxwcmU+dGltZSBhbnl3YXkuIEl0IHdpbGwgdGFrZSBsb25nZXIgdG8gZmV0
Y2ggdGhlIHJlbGV2YW50IFlhbmcgZmlsZSwgdG8gdXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+
dGhlIHRvb2xzIHRvIGdlbmVyYXRlIHRoZSBjb2RlIGFuZCB0byBpbnRlZ3JhdGUgaXQgaW50byB0
aGUgZXhpc3Rpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb2RlIHRoYW4gdG8ganVzdCB3cml0
ZSB0aGVzZSBmZXcgbGluZXMgeW91cnNlbGYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2hhdCB0aGUgYWJvdmUgZXhhbXBsZSBkb2VzIG5vdCB1
dGlsaXplIHBvdGVudGlhbCBjb2RlIGdlbmVyYXRpb24gZm9yPG86cD48L286cD48L3ByZT4NCjxw
cmU+dGhlIGFjdHVhbCBpbnRlcmFjdGlvbiBtb2RlbC4gSW4gbXkgY2FzZSBteSBjb2RlIGlzIGhh
cmQtd2lyZWQgdG8gdXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+TFdNMk0uPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2luY2UgSSBoYXZlIG5v
dCB5ZXQgc2VlbiBhIG1lYW5pbmdmdWwgZXhhbXBsZSBvZiBZYW5nIGZvciB0aGUgSW9UPG86cD48
L286cD48L3ByZT4NCjxwcmU+ZW52aXJvbm1lbnQgSSBhbHNvIGhhdmVuJ3Qgc2VlbiBvbmUgdGhh
dCBwcm9kdWNlcyBtZWFuaW5nZnVsIGNvZGUgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhl
IGludGVyYWN0aW9uIG1vZGVsIGVpdGhlci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRpbmcgKDQpIGNvbmNlcm5pbmcgWWFuZyBhcyBh
IGRhdGEgbW9kZWxsaW5nIGxhbmd1YWdlICh2cy4gb3RoZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5sYW5ndWFnZXMgYWxzbyBjb25zaWRlcmVkIGJ5IHRoZSBJb1QgY29tbXVuaXRpZXMpLiBBcyBQ
YXVsIG5vdGVkIHRoZXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+YXJlIG90aGVyIGxhbmd1YWdl
cyBpbiB0b3duIGFuZCBJIHBlcnNvbmFsbHkgZG8gbm90IGtub3cgd2hldGhlciB0aGU8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5mZWF0dXJlcyBvZmZlcmVkIGJ5IFlhbmcgYXJlIGJldHRlciBvciBl
cXVhbCB0byB0aG9zZSBvZmZlcmVkIGJ5IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm90aGVy
IGxhbmd1YWdlcy4gSSBjZXJ0YWlubHkgaGF2ZW4ndCBkb25lIHRoYXQgYW5hbHlzaXMuPG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QXMgYSBjb25j
bHVkaW5nIHJlbWFyayBJIHdvdWxkIGxpa2UgdG8gc2F5IHRoYXQgd2hpbGUgbXkgY3VycmVudDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFzc2Vzc21lbnQgbWF5IHNvdW5kIG5lZ2F0aXZlIEkgYW0g
aGFwcHkgdG8gbGVhcm4gbW9yZSBhYm91dCB0aGlzIHRvcGljPG86cD48L286cD48L3ByZT4NCjxw
cmU+YW5kIG1pZ2h0IGdldCBjb252aW5jZWQgdGhhdCBZYW5nIGlzIHRoZSByaWdodCB0b29sLiBD
dXJyZW50bHksIEkganVzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhhdmVuJ3QgcmVhY2hlZCB0
aGF0IGxldmVsIHlldCBhbmQgSSBjYW4gY2xhaW0gdGhhdCBJIGhhdmUgc3BlbnQgc29tZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPnRpbWUgbG9va2luZyBhdCB0aGlzIHRvcGljIGFscmVhZHkuPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2lhbzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhhbm5lczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9u
IDA0LzEwLzIwMTYgMDI6MjIgUE0sIENhcnN0ZW4gQm9ybWFubiB3cm90ZTo8bzpwPjwvbzpwPjwv
cHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPkluIEJ1ZW5vcyBBaXJlcywgd2UgZGlzY3Vzc2VkIHRoZSBhZG9wdGlvbiBv
ZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRyYWZ0LXZlaWxsZXR0ZS1jb3JlLXlhbmctY2Jvci1t
YXBwaW5nLTAwIGJ1dCBub3QgZW5vdWdoIHBlb3BsZSBoYWQgcmVhZDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnRoZSBkb2N1bWVudCB0byBnbyBmb3IgYW4gaW4tcm9vbSBjb25zZW5zdXMgY2FsbC48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlz
IGlzIGEgdHdvLXdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5kcmFmdC12ZWlsbGV0dGUtY29yZS15YW5nLWNib3ItbWFwcGluZy0wMCBhcyBhIFdHIGRvY3Vt
ZW50IG9mIENvUkUuPG86cD48L286cD48L3ByZT4NCjxwcmU+U3BlY2lmaWNhbGx5LCBpZiB5b3Ug
KDEpIHN1cHBvcnQgb3IgKDIpIGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoaXM8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5kZWNpc2lvbiwgcGxlYXNlIHNwZWFrIHVwIG9uIHRoZSBtYWlsaW5nIGxpc3Qg
YnkgMjAxNi0wNC0yNC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5Ob3RlIHRoYXQgdGhpcyB3b3JrIGlzIGV4cGxpY2l0bHkgY292ZXJlZCBieSBv
dXIgY2hhcnRlciwgc28gZGlzY3Vzc2lvbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZiB3aGlj
aCBXRyBzaG91bGQgd29yayBvbiB0aGlzIGFyZSBvZmYtdG9waWMuPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QXMgYWx3YXlzLCBhZG9wdGlvbiBv
ZiBhIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQgaXMgbm90IGEgdm90ZSBvbjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPndoZXRoZXIgd2UgYWxyZWFkeSBoYXZlIHJlYWNoZWQgbGFzdC1jYWxsIHN0
YXRlOyB0aGUgaW50ZW50aW9uIGlzIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+d29yayBvbiB0
aGUgV0cgZG9jdW1lbnQgYWZ0ZXIgYWRvcHRpb24gZm9yIGEgd2hpbGUgdG8gZ2V0IGl0IHJlYWR5
IGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxhc3QgY2FsbC4mbmJzcDsgSWYgeW91IHdhbnQg
dG8gY29tYmluZSB5b3VyIHN1cHBvcnQvb2JqZWN0aW9uIHdpdGggdGVjaG5pY2FsPG86cD48L286
cD48L3ByZT4NCjxwcmU+Y29tbWVudHMsIHRoaXMgaXMgY2VydGFpbmx5IHdlbGNvbWUgc28gd2Ug
Y2FuIGFjY2VsZXJhdGUgdGhhdCBwcm9jZXNzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkdyw7zDn2UsIENhcnN0ZW48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvcmUg
bWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNvcmVA
aWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvcmUgbWFpbGluZyBsaXN0PG86cD48
L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2NvcmU8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_BLUPR06MB1763FBD6CA5713264555DBDEFE6E0BLUPR06MB1763namp_--


From nobody Thu Apr 21 13:46:43 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62C412E475 for ; Thu, 21 Apr 2016 13:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 CANX_SUJ8xXT for ; Thu, 21 Apr 2016 13:46:40 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1864412E45D for ; Thu, 21 Apr 2016 13:46:40 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 55AAD9F5; Thu, 21 Apr 2016 22:46:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r9nYx5-HOW0i; Thu, 21 Apr 2016 22:46:18 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Apr 2016 22:46:37 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E6CB20047; Thu, 21 Apr 2016 22:46:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pv1a9c1WpyK2; Thu, 21 Apr 2016 22:46:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78B8020046; Thu, 21 Apr 2016 22:46:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 183373AAD845; Thu, 21 Apr 2016 22:46:30 +0200 (CEST)
Date: Thu, 21 Apr 2016 22:46:30 +0200
From: Juergen Schoenwaelder 
To: Michel Veillette 
Message-ID: <20160421204630.GA8993@elstar.local>
Mail-Followup-To: Michel Veillette , Hannes Tschofenig , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 20:46:41 -0000

On Thu, Apr 21, 2016 at 07:47:53PM +0000, Michel Veillette wrote:
> Hi Juergen
> 
> I'm not sure I can share a LWM2M definition files since peoples need fill a form to get access to them, see the following link.
> 
> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0

Then I can't help.
 
> I didn't go through a formal mapping between these two modeling languages but following is what this mapping might look like:
> 
> LWM2M                | YANG
> ---------------------+---------------
>              | module
>                | module name
>        | description
>   | list if true, container if false
>           | mandatory
>                | leaf if  is true, leaf-list if false
>                | leaf name
>          | config
>   | See 
>           | mandatory
>                | type
>    | range or enum
>               | units
>         | description
>

The devil is usually in the details but since there is no public
specification I do not know. It sounds somewhat surprising that an
'' would equate a YANG module but then I simply do not know.
Only someone who has access to the specifications and who can get
clearance to write about a mapping according to IETF rules can work
on this.

/js

PS: You shall [...] not [...] use all or any part of a Document as part
    of a specification or standard not emanating from the Licensor
    without the prior written consent of the Licensor [...]

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Apr 21 14:00:38 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB62A12E59E for ; Thu, 21 Apr 2016 14:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wus6GWAYMwmU for ; Thu, 21 Apr 2016 14:00:35 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7BB12E502 for ; Thu, 21 Apr 2016 14:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YP4L+Uk+VTHV3o46OCFyq3D1V5V1RmYb5RVBImUDmKc=; b=GDi+k9ADWbOMNEFh7UwSjyMR7wDuel20qdk400ZV4YavivMV8Ue2jv7djOX9Ixk9nLDKAzLJOHTyWm3ligCnEUOvUZJpc1PCGZFcNxq4PgXVzVVpmG54EcPXT9+1S9BzVVupRDDwZUOQH1Dosvon332IibQUCjVphgjm4Efybow=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 21:00:29 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 21:00:29 +0000
From: Michel Veillette 
To: Juergen Schoenwaelder 
Thread-Topic: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
Thread-Index: AQHRm/X9d/034ye6rkCrz4BefXTDrJ+U0HzQgAAVWwCAAAIn4A==
Date: Thu, 21 Apr 2016 21:00:29 +0000
Message-ID: 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>
In-Reply-To: <20160421204630.GA8993@elstar.local>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: 69a18df5-fed0-4f64-792d-08d36a27f879
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:nTK2/0IXkzA/FA0tuz/faxMJzoDtQiEONc9KLFzAr4szyXusBEagb0FrOv/eXhxaaIzH26SPLduHKW/567IwcU/DHbqoQqZVoU2gY9lX51Q0RN4TFe5UqGAsV5FFteDMVPgsVwWI9UFdp+NDzV2vOUi+OG/26q1LwQoZFLGnVBY7BXGfqugNNMBU3FgzQvcQ; 24:fRWt0T8Vj+tXGKxLZahN9MWjGjWRZlpjEBYQ7mrWNs1ULvy3qyNzwg3mznTP+/Umcx+OWcxwZhkNl8NNE3JwbIZlQcDisM6bxigmONDUSR0=; 7:mQTGueVuBvBOmM70PS4vuQlQRNdrrzCdean8fagmcZogG3hP2gohBEfgtJuC/QBDe1sDq7hBEA5F6IuVt1TP6Eem2GuzHk0un9FF2qm6DmU4757G+e8IH4Qr2jns0+NauVPrnRVXBYzHxWnGFX99XUGFd9qvAeO6jPWUUdFcql+ln00DsqNscwyD1yTfTLL2zjOKXG7kY8XlZLCFiG3xzNEIltmLq77siCBLHVJ1Kbs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; 
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(110136002)(15975445007)(1720100001)(122556002)(5002640100001)(2900100001)(586003)(1220700001)(2950100001)(77096005)(66066001)(189998001)(6116002)(102836003)(5003600100002)(92566002)(5008740100001)(93886004)(10400500002)(74316001)(106116001)(87936001)(3660700001)(81166005)(99286002)(3280700002)(5004730100002)(19580405001)(19580395003)(86362001)(9686002)(33656002)(76576001)(76176999)(54356999)(4326007)(50986999)(11100500001)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 21:00:29.2579 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 21:00:37 -0000

Hi Juergen

The extract I have provided is from a publically available document, see:
https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf

My remark about the LWM2M modeling language was just to highlight that such=
 language don't necessary imply code generation.

Regards,
Michel

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: April-21-16 4:47 PM
To: Michel Veillette 
Cc: Hannes Tschofenig ; core@ietf.org WG 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping=
-00

On Thu, Apr 21, 2016 at 07:47:53PM +0000, Michel Veillette wrote:
> Hi Juergen
>=20
> I'm not sure I can share a LWM2M definition files since peoples need fill=
 a form to get access to them, see the following link.
>=20
> http://technical.openmobilealliance.org/Technical/technical-informatio
> n/release-program/current-releases/oma-lightweightm2m-v1-0

Then I can't help.
=20
> I didn't go through a formal mapping between these two modeling languages=
 but following is what this mapping might look like:
>=20
> LWM2M                | YANG
> ---------------------+---------------
>              | module
>                | module name
>        | description
>   | list if true, container if false
>           | mandatory
>                | leaf if  is true, leaf-list if =
false
>                | leaf name
>          | config
>   | See 
>           | mandatory
>                | type
>    | range or enum
>               | units
>         | description
>

The devil is usually in the details but since there is no public specificat=
ion I do not know. It sounds somewhat surprising that an '' would e=
quate a YANG module but then I simply do not know.
Only someone who has access to the specifications and who can get clearance=
 to write about a mapping according to IETF rules can work on this.

/js

PS: You shall [...] not [...] use all or any part of a Document as part
    of a specification or standard not emanating from the Licensor
    without the prior written consent of the Licensor [...]

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Apr 21 14:03:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914E212E214 for ; Thu, 21 Apr 2016 14:03:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3PmqYdLJiE5 for ; Thu, 21 Apr 2016 14:03:17 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0564312D9BC for ; Thu, 21 Apr 2016 14:03:17 -0700 (PDT)
Received: by mail-lb0-x234.google.com with SMTP id b1so29791643lbi.1 for ; Thu, 21 Apr 2016 14:03:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=N3cQ3H5+me0FS9IkcjSEJHpY0ad9W9dKWJ9QWGMrals=; b=dunSIoNKd5+mtdwoKLEDs2Z9p5pfcOjE468gHumLJrx4BPmzvobcympGvYjjJ7xLCu 9354zc2pW98kd0tV0c8nNn+wH2lat9oNjehvGhAvPrw3Y7R0YA1E+pE5KTlmfmkRnyB7 f7jq3cSjMfFK9pVOpbloFWmyGx2WpA/wNNsrQAI4qV89+oIkA9eHZ5C7GcoWFVZ7gla8 xvjbxaHNWfinEHachgQ3A+16vgEtrJnp110Uv3GjJpDMV1ZKu5FX0wEwtbJs7DwFqUJo fMXp0yz39ETIpep6GL1nAUhoDimMJ7PIdoiniTSyzOmYlrGXCuVAUyS9QFaQou+Vsozi THXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=N3cQ3H5+me0FS9IkcjSEJHpY0ad9W9dKWJ9QWGMrals=; b=h/ihg29iTMj4F4JUF03xbru+rGOSpXD9wMPCNAo/Yg79b6P2BCAJ939EMXElTOTMJM 93ykV4CdjRVlvfHETvKXLh5HRh7Phz0xhwVemd+S82xkAmEMS0ONEuCKdNYI0kk6FHqQ CJz96+P6PS6ne60OEZHHWofWTIhOnimwQvxlTr2svA/0ay3J17SyHwiVdtr4QkZnJQpv YqgRfoUTYtIzUZlV/Ka4YYfA114S5zGYycv6WpGFk30Z7hBUIEHn1YAbFyI/VKcor8Ui yPEQ8J3wM6tbzrk/bPrDgIhnud/ilj8PoQwnShoMncTwIDHctSdBMy4nOvInUBnnCu98 zklQ==
X-Gm-Message-State: AOPr4FWECPcYTpFtY3HliEBQLuVB2d0PPfv8G/HFowPMAb12b39fUcLdit8gcxOA3RSmrcBhXQfzKxrhHffJPA==
MIME-Version: 1.0
X-Received: by 10.112.147.101 with SMTP id tj5mr6156151lbb.119.1461272595260;  Thu, 21 Apr 2016 14:03:15 -0700 (PDT)
Received: by 10.112.198.70 with HTTP; Thu, 21 Apr 2016 14:03:15 -0700 (PDT)
In-Reply-To: <20160421204630.GA8993@elstar.local>
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>
Date: Thu, 21 Apr 2016 14:03:15 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  Michel Veillette ,  Hannes Tschofenig , "core@ietf.org WG" 
Content-Type: multipart/alternative; boundary=047d7b3a8bd2f601550531050902
Archived-At: 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 21:03:19 -0000

--047d7b3a8bd2f601550531050902
Content-Type: text/plain; charset=UTF-8

Hi,

I am not advocating a requirements document but it is helpful
to understand them before trying to agree on the details.
It is not just data model or nothing to consider, but what
data modeling features are really needed.

For example, YANG allows decentralized model extension.
Any module can augment another one, without any process
other than writing the module. YANG has many ways
(grouping, leafref, typedef, etc.) to easily reuse other modules.

YANG has the concept of a datastore, not just API input and output.
It has the notion of configuration vs. state, that is also relevant to NM.
Cross-object validation (e.g. must-stmt) and conditional usage (when-stmt)
is important for configuration management. It has advanced support
for module conformance (what is optional to implement? what is optional to
use?)

Is it OK if CoAP is used for purposes outside of IoT?
I think constrained networks are within the charter,
so real network management of  devices on constrained networks
seems relevant to this WG.



Andy




On Thu, Apr 21, 2016 at 1:46 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Apr 21, 2016 at 07:47:53PM +0000, Michel Veillette wrote:
> > Hi Juergen
> >
> > I'm not sure I can share a LWM2M definition files since peoples need
> fill a form to get access to them, see the following link.
> >
> >
> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0
>
> Then I can't help.
>
> > I didn't go through a formal mapping between these two modeling
> languages but following is what this mapping might look like:
> >
> > LWM2M                | YANG
> > ---------------------+---------------
> >              | module
> >                | module name
> >        | description
> >   | list if true, container if false
> >           | mandatory
> >                | leaf if  is true, leaf-list if
> false
> >                | leaf name
> >          | config
> >   | See 
> >           | mandatory
> >                | type
> >    | range or enum
> >               | units
> >         | description
> >
>
> The devil is usually in the details but since there is no public
> specification I do not know. It sounds somewhat surprising that an
> '' would equate a YANG module but then I simply do not know.
> Only someone who has access to the specifications and who can get
> clearance to write about a mapping according to IETF rules can work
> on this.
>
> /js
>
> PS: You shall [...] not [...] use all or any part of a Document as part
>     of a specification or standard not emanating from the Licensor
>     without the prior written consent of the Licensor [...]
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--047d7b3a8bd2f601550531050902
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I am not advocating a requirements =
document but it is helpful
to understand them before trying to ag=
ree on the details.
It is not just data model or nothing to consi=
der, but what
data modeling features are really needed.

For example, YANG allows decentralized model extension.
Any module can augment another one, without any process
ot=
her than writing the module. YANG has many ways
(grouping, leafre=
f, typedef, etc.) to easily reuse other modules.

Y=
ANG has the concept of a datastore, not just API input and output.
It has the notion of configuration vs. state, that is also relevant to NM=
.
Cross-object validation (e.g. must-stmt) and conditional usage =
(when-stmt)
is important for configuration management. It has adv=
anced support
for module conformance (what is optional to impleme=
nt? what is optional to use?)

Is it OK if CoAP is =
used for purposes outside of IoT?
I think constrained networks ar=
e within the charter,
so real network management of =C2=A0devices=
 on constrained networks
seems relevant to this WG.


Andy



On Thu, Apr 21, 2016 at 1:46 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">On Thu, Apr 21, 2016 at 07:47:53PM +0000, Mic=
hel Veillette wrote:

> Hi Juergen

>

> I'm not sure I can share a LWM2M definition files since peoples ne=
ed fill a form to get access to them, see the following link.

>

> http://technical.openmobilealliance.org/T=
echnical/technical-information/release-program/current-releases/oma-lightwe=
ightm2m-v1-0



Then I can't help.



> I didn't go through a formal mapping between these two modeling la=
nguages but following is what this mapping might look like:

>

> LWM2M=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | YANG
> ---------------------+---------------

> <Object>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| module=


> <Name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| m=
odule name

> <Description1>=C2=A0 =C2=A0 =C2=A0 =C2=A0| description

> <MultipleInstances>=C2=A0 | list if true, container if false

> <Mandatory>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | mandatory

> <Item>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| l=
eaf if <MultipleInstances> is true, leaf-list if false

>=C2=A0 <Name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | l=
eaf name

>=C2=A0 <Operations>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | config

>=C2=A0 <MultipleInstances> | See <Item>

>=C2=A0 <Mandatory>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| mandatory
>=C2=A0 <Type>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | t=
ype

>=C2=A0 <RangeEnumeration>=C2=A0 | range or enum

>=C2=A0 <Units>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| u=
nits

>=C2=A0 <Description>=C2=A0 =C2=A0 =C2=A0 =C2=A0| description

>



The devil is usually in the details but since there is no public

specification I do not know. It sounds somewhat surprising that an

'<Object>' would equate a YANG module but then I simply do no=
t know.

Only someone who has access to the specifications and who can get

clearance to write about a mapping according to IETF rules can work

on this.



/js



PS: You shall [...] not [...] use all or any part of a Document as part

=C2=A0 =C2=A0 of a specification or standard not emanating from the Licenso=
r

=C2=A0 =C2=A0 without the prior written consent of the Licensor [...]



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core





--047d7b3a8bd2f601550531050902--


From nobody Thu Apr 21 14:37:54 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5C12D9A3 for ; Thu, 21 Apr 2016 14:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 y47r9bwh2H7F for ; Thu, 21 Apr 2016 14:37:50 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120E312D116 for ; Thu, 21 Apr 2016 14:37:49 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCEAC779; Thu, 21 Apr 2016 23:37:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mI4STz27MHdC; Thu, 21 Apr 2016 23:37:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Apr 2016 23:37:46 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5AEBA2004A; Thu, 21 Apr 2016 23:37:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id etCQpvUbOolC; Thu, 21 Apr 2016 23:37:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B57C20046; Thu, 21 Apr 2016 23:37:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F36843AADB2A; Thu, 21 Apr 2016 23:37:42 +0200 (CEST)
Date: Thu, 21 Apr 2016 23:37:42 +0200
From: Juergen Schoenwaelder 
To: Michel Veillette 
Message-ID: <20160421213738.GD8993@elstar.local>
Mail-Followup-To: Michel Veillette , Hannes Tschofenig , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 21:37:53 -0000

On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Veillette wrote:
> Hi Juergen
> 
> The extract I have provided is from a publically available document, see:
> https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf
> 
> My remark about the LWM2M modeling language was just to highlight that such language don't necessary imply code generation.
>

YANG does not imply code generation either. A YANG module defines a
contract, and in the light of a protocol a programmatic interface.
There is nothing in YANG that requires code generation.

It just happens that people often tend to automate things if they find
themself repeatedly writing similar code. It is at the end a question
of how much data a device exposes and what kind of developers you are
dealing with and whether you have a product that is expected to evolve
over years or something designed to be sold and thrown away
afterwards. ;-)

/js

PS: I have just implemented a YANG data model 'manually' because I had
    reasons to not depend on tool chains (the target environment are
    OpenWrt type of devices). But still I took advantage of having
    YANG tools available to validate test cases so that I can be
    reasonably sure my manually written code is a good match of the
    contract.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Apr 21 14:50:04 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584D112DB60 for ; Thu, 21 Apr 2016 14:50:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-DxriDHRfyt for ; Thu, 21 Apr 2016 14:50:01 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 90B1412D7B5 for ; Thu, 21 Apr 2016 14:50:00 -0700 (PDT)
Received: by mail-lb0-x231.google.com with SMTP id b1so30237740lbi.1 for ; Thu, 21 Apr 2016 14:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=R4CH3DGydlxsKwc/qfVHzHQfVWShA9wWLCJR+DVqJhI=; b=Kp59iHKHK+tw5rXKl9po1EgdRmBalVQAPnGyQPv0X7Q/yzTBO/4qvcq5DFzK8MaRPY 89MSHLMBIbjLrugewL6v32Q4AP3feZqdsSlurHrQlHbmJu3J1w5IhXaCBr3fRP7//nuj ujuordAhXoMfT6Zjdl3PBwqWrPSdBWHao/7ZDWs+W1tiyJ4Xh1JsoxodzXfI6ZI0VDis YVBKtnglyiahpnWHE+tK63EMDYazeYbID7mVI5gqmA1e8dx4QGUQ7vJ8qXs0DTl6d9Yb oNAGqj53b5XRX11dnFPZx3b9PVmImIg+t4djLO+i0s0w+TRY4A8TSgSSausjRIiD7R6I UoCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=R4CH3DGydlxsKwc/qfVHzHQfVWShA9wWLCJR+DVqJhI=; b=DBxLKLFYHTT41kV2fUe0xUgHNCEP4ysejqw2vQ2IyXo6UIGNudPas68pzQTPVsvV2o ZvuCK2KZWwTT4v6mqd1ikGnCTTVjTZ7lCuW7YBiGxbaaMUL+0ftsIRQBzjOkhPjuM3AU SMJK1dIqfMrf0aJgpdHLagFw7Q+reEw8GUQIFVhsTzGiUzc1JizJqbuZklAs/XcOkjHr w+3qC0kU7L27wQM4nhXz+JZEurD2IBcVzE6I2De8rfIkTBusda4vv3nQNRrTzCMMeoAa 3OxtACHXX7OfVtsa/mG6s4u77kTOd6p243lssvvFtkvGMXS/NjyGV+FzCQR30BCMcz6D wQdw==
X-Gm-Message-State: AOPr4FXLzrNLku976zQaOx+QmQ0FslxkMgChvXAnYOu/SjNFHsbOPa+52AvkXsxyzZLKdbiS0q3fyShpmnwpYQ==
MIME-Version: 1.0
X-Received: by 10.112.170.68 with SMTP id ak4mr6225849lbc.94.1461275398786; Thu, 21 Apr 2016 14:49:58 -0700 (PDT)
Received: by 10.112.198.70 with HTTP; Thu, 21 Apr 2016 14:49:58 -0700 (PDT)
In-Reply-To: <20160421213738.GD8993@elstar.local>
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>  <20160421213738.GD8993@elstar.local>
Date: Thu, 21 Apr 2016 14:49:58 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  Michel Veillette ,  Hannes Tschofenig , "core@ietf.org WG" 
Content-Type: multipart/alternative; boundary=001a11c259a8106c3b053105b1a3
Archived-At: 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Apr 2016 21:50:03 -0000

--001a11c259a8106c3b053105b1a3
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Veillette wrote:
> > Hi Juergen
> >
> > The extract I have provided is from a publically available document, see:
> > https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf
> >
> > My remark about the LWM2M modeling language was just to highlight that
> such language don't necessary imply code generation.
> >
>
> YANG does not imply code generation either. A YANG module defines a
> contract, and in the light of a protocol a programmatic interface.
> There is nothing in YANG that requires code generation.
>
> It just happens that people often tend to automate things if they find
> themself repeatedly writing similar code. It is at the end a question
> of how much data a device exposes and what kind of developers you are
> dealing with and whether you have a product that is expected to evolve
> over years or something designed to be sold and thrown away
> afterwards. ;-)
>
> /js
>
> PS: I have just implemented a YANG data model 'manually' because I had
>     reasons to not depend on tool chains (the target environment are
>     OpenWrt type of devices). But still I took advantage of having
>     YANG tools available to validate test cases so that I can be
>     reasonably sure my manually written code is a good match of the
>     contract.
>
>

There are commercial and open-source toolchains that handle the NETCONF/YANG
interaction model and most of the data model details in the protocol stack,
instead of pushing that
work out to the model instrumentation.  This can save a lot of code and
makes sure
the client or server has consistent behavior.

But you are making an important point.
The expected use CoMI/CoOL co-authors have discussed is client firmware
written
to work with specific YANG modules/revisions.  The client needs to retrieve
enough
server state to know if the server supports the same module revisions, and
then just assumes
the API contract will be followed.  It does not need any YANG parser or
code automation.


--
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
>

Andy


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

--001a11c259a8106c3b053105b1a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Vei=
llette wrote:

> Hi Juergen

>

> The extract I have provided is from a publically available document, s=
ee:

> https://www.iab.org/wp-content=
/IAB-uploads/2016/03/ipso-paper.pdf

>

> My remark about the LWM2M modeling language was just to highlight that=
 such language don't necessary imply code generation.

>



YANG does not imply code generation either. A YANG module defines a

contract, and in the light of a protocol a programmatic interface.

There is nothing in YANG that requires code generation.



It just happens that people often tend to automate things if they find

themself repeatedly writing similar code. It is at the end a question

of how much data a device exposes and what kind of developers you are

dealing with and whether you have a product that is expected to evolve

over years or something designed to be sold and thrown away

afterwards. ;-)



/js



PS: I have just implemented a YANG data model 'manually' because I =
had

=C2=A0 =C2=A0 reasons to not depend on tool chains (the target environment =
are

=C2=A0 =C2=A0 OpenWrt type of devices). But still I took advantage of havin=
g

=C2=A0 =C2=A0 YANG tools available to validate test cases so that I can be<=
br>
=C2=A0 =C2=A0 reasonably sure my manually written code is a good match of t=
he

=C2=A0 =C2=A0 contract.




There are commercial and open-source =
toolchains that handle the NETCONF/YANG
interaction model and mos=
t of the data model details in the protocol stack, instead of pushing that<=
/div>
work out to the model instrumentation.=C2=A0 This can save a lot =
of code and makes sure
the client or server has consistent behavi=
or.

But you are making an important point.
The expected use CoMI/CoOL co-authors have discussed is client firmware =
written
to work with specific YANG modules/revisions.=C2=A0 The c=
lient needs to retrieve enough
server state to know if the server=
 supports the same module revisions, and then just assumes
the AP=
I contract will be followed.=C2=A0 It does not need any YANG parser or code=
 automation.



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>




Andy
=C2=A0

_______________________________________________

core mailing list

core@ietf.org

https://www.ietf.org/mailman/listinfo/core





--001a11c259a8106c3b053105b1a3--


From nobody Fri Apr 22 01:41:21 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0143812D7D9 for ; Fri, 22 Apr 2016 01:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 DuWiHPM8nr8H for ; Fri, 22 Apr 2016 01:41:18 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF69912D87A for ; Fri, 22 Apr 2016 01:41:17 -0700 (PDT)
Received: from [192.168.10.140] ([138.232.236.15]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mhdex-1b6wfZ1Efr-00Mtli; Fri, 22 Apr 2016 10:41:14 +0200
To: timothy.carey@nokia.com
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5719E3B0.5050001@gmx.net>
Date: Fri, 22 Apr 2016 10:41:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Awf5fGBCsW86F7lNfwvcNgmGGeSRV9b4H"
X-Provags-ID: V03:K0:nhIyneuHQR54rkdEfSWjAqju6o3H9kZYtU9L4dZCbuOzWDpfysv Ph2cOgAW3bc8p4UDRn/f2p2n0sLzDkohslMcwWX19cfJRdAAiX/lb7ruccJ3cbFWcFw43O1 l7SlpQAWCptFwtOXjG7cwI6gctxBtAF5uFgVQLASeRiVql+PAgju85QnQVI7BYW6YuxY5GJ 5fXW45/2gEXBUkXmo9siw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:RE0PNk9LH1Q=:EHP43AELG0I8phTtzQYe9e v0vZCmpX+iuwsS2h756VUswJBfOOK6lkgKCEgNRSkqAVewGeW+ujHM3g1SS1uaKSar60YYanC /N7N/HrGthBswXtpRS912mozlJEGtUlczIqYdhNkX9odwMSUnRO9GK9/uN+cNqHDqNNaAmFLR zuVr9du/sJxwT4iXislv1y/mwmTdjjWCZHhLbuxeeZ4aoKmgA6os+zfFMklvfSMgXaiyBPjFG SYjDFT18hcgsec00bbuA8Yr9LEOsIrpEQTxmhQx1iNJebt2J+D4/7bP+2o03E6BdbqaZUBfWR Lwj4NXfdcRaiBNLKeU+rO0/uFIGUyfa93Yd9feGjXXhMYj09LnqQCvoq7G11nMufyaQ90BpuP qgb3Rq3qdomcxJxbvcGEWEtQrP7KA+mBsgVBxy5D7+cxNjQZ558dWHjWQKgxCfhDigc02ydT5 hADlemjDy0HwVA0A9p7p6oMs58bt5AMbh2xxAdgm2rK0p++tlee4ynZ5JevqFIl/WmWBMEQeS 2mNS5XD20USfAWfdutrFoy+j7pBlp7PgLIPdwUe2DM9JVar2zQ5RcJLPyuQROKcDTJvTqrPz6 PE6F6uETqrl9cjJHiH/SuaEL148ZKBancLIytgVmx3/7lY9ZEF6QqUX583mwSxjxL9IrRIMEM 7ibxgJymmizQLmw4GxQH4nOREgIl2QttjXIib6PIPPiRL4RU+wUuvofswvcgo1zwSx6RphKxZ KgOX3kcRhqSmrjbciTZCYdpfDS8PwMUvUnrywD8IDqkfPR1BaAfWxEu0OQc=
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: [core] CON usage with CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 08:41:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Awf5fGBCsW86F7lNfwvcNgmGGeSRV9b4H
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Tim,

please double-check whether you agree that the new draft submission and
the change of the encoding of the length format indeed addressed the
issue you raised. Here is the link to the issue:
https://trac.tools.ietf.org/wg/core/trac/ticket/397#comment:1

Ciao
Hannes


--Awf5fGBCsW86F7lNfwvcNgmGGeSRV9b4H
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXGeOxAAoJEGhJURNOOiAtomMH/0mcTsOFcNqac91+TZAe8upc
XS3YxWUWk0cuB/FnOpKIdDJzLGMgYoKsgOpiP7dCb2WWbGvA/lp+th3ubdotzypu
o6ha93JCl1zzUwjvy9t3mKYpo0gXAqdT683CY35WJ9RwcfLl1peyjBH4t/a1iNuv
PL9kW/azQdYHG5cZ/fOX6g1Myg/w4BceywekQ4Xy0/KQCKkv19Q7kf9SKu98d8dO
iX8bmBy1nNTlSPWsTaaHVauMA2bEW8gimdMfGvMz3otrFcwqHY76FupQsqvcdSrm
9xijmjvxxPJszWpKFZEYUBrPCOasndKhDdR4uCjaC8erzSAtZYxG7Aka5usF5A8=
=fx0/
-----END PGP SIGNATURE-----

--Awf5fGBCsW86F7lNfwvcNgmGGeSRV9b4H--


From nobody Fri Apr 22 01:47:20 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A712EA62 for ; Fri, 22 Apr 2016 01:47:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 kr6hQCNuA9Z0 for ; Fri, 22 Apr 2016 01:47:15 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4597E12EA61 for ; Fri, 22 Apr 2016 01:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com;  s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZQnnkd9PAuy2YDHcK0aQm8ILav1ICC31eCXrcX6/4GA=; b=X+BbHdCAcx1DiDieB8MX4X+QghqSQqCWWHP+QpXzP7f/r1nYc/jvZYfdBJRm6muglprGGNFLFFAllN9v9yCXBjP5X/4/zRhh+AJbMeDRGIXq5MP82gej22Q3DHhha6EB9PJQMi7bWRDC3QV1quMbRlz3jGR1bnq/tUITPf+ntrw=
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1837.eurprd06.prod.outlook.com (10.165.237.155) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 08:46:50 +0000
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0466.023; Fri, 22 Apr 2016 08:46:50 +0000
From: Somaraju Abhinav 
To: Andy Bierman , Juergen Schoenwaelder , Michel Veillette , Hannes Tschofenig , "core@ietf.org WG" 
Thread-Topic: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
Thread-Index: AQHRm/X+5ubwG7D3zkGKYQfJYUlSTp+U1XaAgAAQYQCAAAPogIAACmYAgAADbQCAALSEcA==
Date: Fri, 22 Apr 2016 08:46:50 +0000
Message-ID: 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>  <20160421213738.GD8993@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=tridonic.com; 
x-originating-ip: [146.108.200.10]
x-ms-office365-filtering-correlation-id: c2e39b42-c687-4469-91c8-08d36a8aa576
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1837; 5:PhHisXZ0Gy35+3bMOTIWHuNR1qfH0TlW43hLD6DDdOELne3dkEyHRmUEU6QxUE9KBgLgIU5mLoXez1zF6SIUlAgloziPn3mLG3c3f1AarJoYKN6MCXKI9fCBPZz7CI2YPW7Y0XE9YJtvkLDptgEfHA9qB9V0T9d4H2yLSFxwIhKx1ts1GPSOQWM7sLRbmCwl; 24:K/MRdNdqmCWYuObS/WqOAzi335OIx2rze8jMqJbEOOlklmZwK6ukn39l4+qapNpjgjARMthpCnBEgVpAVXS6sS4Y7N13AjQeYTB1weaRRM4=; 7:QVqRYl64NxHNN2P/TOsYB0qDBz1Evm7DDzmG6cai3SWbc79wndimRW9MnLo24Y6MeBD8KAJgQrQeGGIV4f9Woi/FMcF0z7orgcDr8/0/GTAPclWcoR1v+a6PCgXo0sXFgk5MLZFrAJ8oziqBAEGms2EsC0TeBTDStwvGfV+PwGSyP6m948rkhxCy9Y3r6MCOFm2cdt+5ROwRtThN8PhAnLVpADd83HTeuTJCnDjZOFs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1837;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415293)(102615271)(9101521026)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR06MB1837; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1837; 
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(76576001)(189998001)(5003600100002)(5890100001)(66066001)(19580405001)(19580395003)(92566002)(10400500002)(2906002)(107886002)(19617315012)(230783001)(5008740100001)(74316001)(6116002)(790700001)(33656002)(19300405004)(586003)(81166005)(2900100001)(15975445007)(3280700002)(50986999)(3846002)(102836003)(54356999)(77096005)(5001770100001)(99936001)(1220700001)(87936001)(2950100001)(76176999)(16236675004)(1096002)(5004730100002)(122556002)(106116001)(5002640100001)(9686002)(86362001)(3660700001)(93886004)(11100500001)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1837; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_004_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_"
MIME-Version: 1.0
X-OriginatorOrg: tridonic.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2016 08:46:50.1382 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1837
Archived-At: 
Subject: Re: [core] ? WG adoption of	draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 08:47:18 -0000

--_004_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_
Content-Type: multipart/alternative;
	boundary="_000_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_"

--_000_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQpXZSBoYXZlIGJlZW4gdXNpbmcgWUFORyB0byBtb2RlbCBvYmplY3RzIHRoYXQgd2UgdXNl
IHdpdGggTFdNMk0gZm9yIGFib3V0IDYgbW9udGhzIG5vdy4gQXMgZmFyIGFzIEkgY2FuIHRlbGws
IHRoZXJlIGlzIG9ubHkgb25lIHBhcnQgb2YgdGhlIExXTTJNIHJlc291cmNlIG1vZGVsIHRoYXQg
Y2Fubm90IGJlIG1vZGVsbGVkIHVzaW5nIFlBTkc6IExXTTJNIGhhcyByZXNvdXJjZXMgb24gd2hp
Y2ggeW91IGNhbiByZWFkLCB3cml0ZSBhbmQgZXhlY3V0ZSAob3BlcmF0aW9ucykuIFlBTkcgZGlz
dGluZ3Vpc2hlcyBiZXR3ZWVuIHJlc291cmNlcyB0aGF0IGFyZSBvcGVyYXRpb25zIHZzIGRhdGEg
YW5kIHRoZXJlZm9yZSBjYW5ub3QgYmUgdXNlZCB0byBtb2RlbCByZXNvdXJjZXMgaW4gTFdNMk0g
dGhhdCBzdXBwb3J0IHRoZSB0aHJlZSB0eXBlcyBvZiBvcGVyYXRpb25zLiBUaGVyZSBhcmUgb2Yg
Y291cnNlIHdheXMgYXJvdW5kIHRoaXMgaXNzdWUuDQoNCkFzIGFuIGV4YW1wbGUsIHBsZWFzZSBm
aW5kIGF0dGFjaGVkIGFuIElQU08gb2JqZWN0IGF2YWlsYWJsZSBmb3IgZG93bmxvYWQgYXQgaHR0
cDovL3d3dy5pcHNvLWFsbGlhbmNlLm9yZy9zby1zdGFydGVyLXBhY2svIHdoaWNoIG15IGNvbGxl
YWd1ZSBoYXMgbW9kZWxsZWQgaW4gWUFORy4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgWUFORyBtb2Rl
bCBpcyBqdXN0IGFuIGV4YW1wbGUgYW5kIGlzIG5vdCBhcHByb3ZlZC9lbmRvcnNlZCBieSBJUFNP
IG9yIExXTTJNLg0KDQpSZWdhcmRzLA0KQWJoaW5hdg0KDQpGcm9tOiBjb3JlIFttYWlsdG86Y29y
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBEb25u
ZXJzdGFnLCAyMS4gQXByaWwgMjAxNiAyMzo1MA0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsgTWljaGVsIFZlaWxsZXR0ZSA8
TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPjsgSGFubmVzIFRzY2hvZmVuaWcgPGhh
bm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+OyBjb3JlQGlldGYub3JnIFdHIDxjb3JlQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFtjb3JlXSA/IFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXZlaWxsZXR0ZS1j
b3JlLXlhbmctY2Jvci1tYXBwaW5nLTAwDQoNCg0KDQpPbiBUaHUsIEFwciAyMSwgMjAxNiBhdCAy
OjM3IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p
dmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4g
d3JvdGU6DQpPbiBUaHUsIEFwciAyMSwgMjAxNiBhdCAwOTowMDoyOVBNICswMDAwLCBNaWNoZWwg
VmVpbGxldHRlIHdyb3RlOg0KPiBIaSBKdWVyZ2VuDQo+DQo+IFRoZSBleHRyYWN0IEkgaGF2ZSBw
cm92aWRlZCBpcyBmcm9tIGEgcHVibGljYWxseSBhdmFpbGFibGUgZG9jdW1lbnQsIHNlZToNCj4g
aHR0cHM6Ly93d3cuaWFiLm9yZy93cC1jb250ZW50L0lBQi11cGxvYWRzLzIwMTYvMDMvaXBzby1w
YXBlci5wZGYNCj4NCj4gTXkgcmVtYXJrIGFib3V0IHRoZSBMV00yTSBtb2RlbGluZyBsYW5ndWFn
ZSB3YXMganVzdCB0byBoaWdobGlnaHQgdGhhdCBzdWNoIGxhbmd1YWdlIGRvbid0IG5lY2Vzc2Fy
eSBpbXBseSBjb2RlIGdlbmVyYXRpb24uDQo+DQoNCllBTkcgZG9lcyBub3QgaW1wbHkgY29kZSBn
ZW5lcmF0aW9uIGVpdGhlci4gQSBZQU5HIG1vZHVsZSBkZWZpbmVzIGENCmNvbnRyYWN0LCBhbmQg
aW4gdGhlIGxpZ2h0IG9mIGEgcHJvdG9jb2wgYSBwcm9ncmFtbWF0aWMgaW50ZXJmYWNlLg0KVGhl
cmUgaXMgbm90aGluZyBpbiBZQU5HIHRoYXQgcmVxdWlyZXMgY29kZSBnZW5lcmF0aW9uLg0KDQpJ
dCBqdXN0IGhhcHBlbnMgdGhhdCBwZW9wbGUgb2Z0ZW4gdGVuZCB0byBhdXRvbWF0ZSB0aGluZ3Mg
aWYgdGhleSBmaW5kDQp0aGVtc2VsZiByZXBlYXRlZGx5IHdyaXRpbmcgc2ltaWxhciBjb2RlLiBJ
dCBpcyBhdCB0aGUgZW5kIGEgcXVlc3Rpb24NCm9mIGhvdyBtdWNoIGRhdGEgYSBkZXZpY2UgZXhw
b3NlcyBhbmQgd2hhdCBraW5kIG9mIGRldmVsb3BlcnMgeW91IGFyZQ0KZGVhbGluZyB3aXRoIGFu
ZCB3aGV0aGVyIHlvdSBoYXZlIGEgcHJvZHVjdCB0aGF0IGlzIGV4cGVjdGVkIHRvIGV2b2x2ZQ0K
b3ZlciB5ZWFycyBvciBzb21ldGhpbmcgZGVzaWduZWQgdG8gYmUgc29sZCBhbmQgdGhyb3duIGF3
YXkNCmFmdGVyd2FyZHMuIDstKQ0KDQovanMNCg0KUFM6IEkgaGF2ZSBqdXN0IGltcGxlbWVudGVk
IGEgWUFORyBkYXRhIG1vZGVsICdtYW51YWxseScgYmVjYXVzZSBJIGhhZA0KICAgIHJlYXNvbnMg
dG8gbm90IGRlcGVuZCBvbiB0b29sIGNoYWlucyAodGhlIHRhcmdldCBlbnZpcm9ubWVudCBhcmUN
CiAgICBPcGVuV3J0IHR5cGUgb2YgZGV2aWNlcykuIEJ1dCBzdGlsbCBJIHRvb2sgYWR2YW50YWdl
IG9mIGhhdmluZw0KICAgIFlBTkcgdG9vbHMgYXZhaWxhYmxlIHRvIHZhbGlkYXRlIHRlc3QgY2Fz
ZXMgc28gdGhhdCBJIGNhbiBiZQ0KICAgIHJlYXNvbmFibHkgc3VyZSBteSBtYW51YWxseSB3cml0
dGVuIGNvZGUgaXMgYSBnb29kIG1hdGNoIG9mIHRoZQ0KICAgIGNvbnRyYWN0Lg0KDQoNClRoZXJl
IGFyZSBjb21tZXJjaWFsIGFuZCBvcGVuLXNvdXJjZSB0b29sY2hhaW5zIHRoYXQgaGFuZGxlIHRo
ZSBORVRDT05GL1lBTkcNCmludGVyYWN0aW9uIG1vZGVsIGFuZCBtb3N0IG9mIHRoZSBkYXRhIG1v
ZGVsIGRldGFpbHMgaW4gdGhlIHByb3RvY29sIHN0YWNrLCBpbnN0ZWFkIG9mIHB1c2hpbmcgdGhh
dA0Kd29yayBvdXQgdG8gdGhlIG1vZGVsIGluc3RydW1lbnRhdGlvbi4gIFRoaXMgY2FuIHNhdmUg
YSBsb3Qgb2YgY29kZSBhbmQgbWFrZXMgc3VyZQ0KdGhlIGNsaWVudCBvciBzZXJ2ZXIgaGFzIGNv
bnNpc3RlbnQgYmVoYXZpb3IuDQoNCkJ1dCB5b3UgYXJlIG1ha2luZyBhbiBpbXBvcnRhbnQgcG9p
bnQuDQpUaGUgZXhwZWN0ZWQgdXNlIENvTUkvQ29PTCBjby1hdXRob3JzIGhhdmUgZGlzY3Vzc2Vk
IGlzIGNsaWVudCBmaXJtd2FyZSB3cml0dGVuDQp0byB3b3JrIHdpdGggc3BlY2lmaWMgWUFORyBt
b2R1bGVzL3JldmlzaW9ucy4gIFRoZSBjbGllbnQgbmVlZHMgdG8gcmV0cmlldmUgZW5vdWdoDQpz
ZXJ2ZXIgc3RhdGUgdG8ga25vdyBpZiB0aGUgc2VydmVyIHN1cHBvcnRzIHRoZSBzYW1lIG1vZHVs
ZSByZXZpc2lvbnMsIGFuZCB0aGVuIGp1c3QgYXNzdW1lcw0KdGhlIEFQSSBjb250cmFjdCB3aWxs
IGJlIGZvbGxvd2VkLiAgSXQgZG9lcyBub3QgbmVlZCBhbnkgWUFORyBwYXJzZXIgb3IgY29kZSBh
dXRvbWF0aW9uLg0KDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29i
cyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAg
ICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEg
MjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg0K
QW5keQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Y29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gVGhlIGNvbnRlbnRz
IG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVz
ZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVu
ZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFz
ZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5k
IGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIg
bm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZp
cnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvciBvdGhlcndpc2Ug
Y2hlY2sgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4NCg==

--_000_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls
U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGhhdmUgYmVlbiB1c2luZyBZQU5H
IHRvIG1vZGVsIG9iamVjdHMgdGhhdCB3ZSB1c2Ugd2l0aCBMV00yTSBmb3IgYWJvdXQgNiBtb250
aHMgbm93LiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlcmUgaXMgb25seSBvbmUgcGFydCBvZiB0
aGUgTFdNMk0gcmVzb3VyY2UgbW9kZWwNCiB0aGF0IGNhbm5vdCBiZSBtb2RlbGxlZCB1c2luZyBZ
QU5HOiBMV00yTSBoYXMgcmVzb3VyY2VzIG9uIHdoaWNoIHlvdSBjYW4gcmVhZCwgd3JpdGUgYW5k
IGV4ZWN1dGUgKG9wZXJhdGlvbnMpLiBZQU5HIGRpc3Rpbmd1aXNoZXMgYmV0d2VlbiByZXNvdXJj
ZXMgdGhhdCBhcmUgb3BlcmF0aW9ucyB2cyBkYXRhIGFuZCB0aGVyZWZvcmUgY2Fubm90IGJlIHVz
ZWQgdG8gbW9kZWwgcmVzb3VyY2VzIGluIExXTTJNIHRoYXQgc3VwcG9ydCB0aGUgdGhyZWUNCiB0
eXBlcyBvZiBvcGVyYXRpb25zLiBUaGVyZSBhcmUgb2YgY291cnNlIHdheXMgYXJvdW5kIHRoaXMg
aXNzdWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgYW4g
ZXhhbXBsZSwgcGxlYXNlIGZpbmQgYXR0YWNoZWQgYW4gSVBTTyBvYmplY3QgYXZhaWxhYmxlIGZv
ciBkb3dubG9hZCBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pcHNvLWFsbGlhbmNlLm9yZy9zby1z
dGFydGVyLXBhY2svIj5odHRwOi8vd3d3Lmlwc28tYWxsaWFuY2Uub3JnL3NvLXN0YXJ0ZXItcGFj
ay88L2E+IHdoaWNoIG15IGNvbGxlYWd1ZSBoYXMgbW9kZWxsZWQgaW4gWUFORy4gUGxlYXNlIG5v
dGUgdGhhdCB0aGUgWUFORyBtb2RlbCBpcyBqdXN0IGFuIGV4YW1wbGUgYW5kIGlzIG5vdCBhcHBy
b3ZlZC9lbmRvcnNlZCBieSBJUFNPIG9yIExXTTJNLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BYmhpbmF2PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gY29yZSBbbWFpbHRvOmNvcmUtYm91bmNl
c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+U2Vu
dDo8L2I+IERvbm5lcnN0YWcsIDIxLiBBcHJpbCAyMDE2IDIzOjUwPGJyPg0KPGI+VG86PC9iPiBK
dWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZSZndDs7IE1pY2hlbCBWZWlsbGV0dGUgJmx0O01pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50
aW5jLmNvbSZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgu
bmV0Jmd0OzsgY29yZUBpZXRmLm9yZyBXRyAmbHQ7Y29yZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtjb3JlXSA/IFdHIGFkb3B0aW9uIG9mIGRyYWZ0LXZlaWxsZXR0ZS1j
b3JlLXlhbmctY2Jvci1tYXBwaW5nLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1
LCBBcHIgMjEsIDIwMTYgYXQgMjozNyBQTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBo
cmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9
Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+T24gVGh1LCBBcHIgMjEsIDIwMTYgYXQgMDk6MDA6MjlQTSAmIzQzOzAwMDAsIE1pY2hl
bCBWZWlsbGV0dGUgd3JvdGU6PGJyPg0KJmd0OyBIaSBKdWVyZ2VuPGJyPg0KJmd0Ozxicj4NCiZn
dDsgVGhlIGV4dHJhY3QgSSBoYXZlIHByb3ZpZGVkIGlzIGZyb20gYSBwdWJsaWNhbGx5IGF2YWls
YWJsZSBkb2N1bWVudCwgc2VlOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFiLm9y
Zy93cC1jb250ZW50L0lBQi11cGxvYWRzLzIwMTYvMDMvaXBzby1wYXBlci5wZGYiIHRhcmdldD0i
X2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlhYi5vcmcvd3AtY29udGVudC9JQUItdXBsb2Fkcy8yMDE2
LzAzL2lwc28tcGFwZXIucGRmPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IE15IHJlbWFyayBhYm91
dCB0aGUgTFdNMk0gbW9kZWxpbmcgbGFuZ3VhZ2Ugd2FzIGp1c3QgdG8gaGlnaGxpZ2h0IHRoYXQg
c3VjaCBsYW5ndWFnZSBkb24ndCBuZWNlc3NhcnkgaW1wbHkgY29kZSBnZW5lcmF0aW9uLjxicj4N
CiZndDs8YnI+DQo8YnI+DQpZQU5HIGRvZXMgbm90IGltcGx5IGNvZGUgZ2VuZXJhdGlvbiBlaXRo
ZXIuIEEgWUFORyBtb2R1bGUgZGVmaW5lcyBhPGJyPg0KY29udHJhY3QsIGFuZCBpbiB0aGUgbGln
aHQgb2YgYSBwcm90b2NvbCBhIHByb2dyYW1tYXRpYyBpbnRlcmZhY2UuPGJyPg0KVGhlcmUgaXMg
bm90aGluZyBpbiBZQU5HIHRoYXQgcmVxdWlyZXMgY29kZSBnZW5lcmF0aW9uLjxicj4NCjxicj4N
Ckl0IGp1c3QgaGFwcGVucyB0aGF0IHBlb3BsZSBvZnRlbiB0ZW5kIHRvIGF1dG9tYXRlIHRoaW5n
cyBpZiB0aGV5IGZpbmQ8YnI+DQp0aGVtc2VsZiByZXBlYXRlZGx5IHdyaXRpbmcgc2ltaWxhciBj
b2RlLiBJdCBpcyBhdCB0aGUgZW5kIGEgcXVlc3Rpb248YnI+DQpvZiBob3cgbXVjaCBkYXRhIGEg
ZGV2aWNlIGV4cG9zZXMgYW5kIHdoYXQga2luZCBvZiBkZXZlbG9wZXJzIHlvdSBhcmU8YnI+DQpk
ZWFsaW5nIHdpdGggYW5kIHdoZXRoZXIgeW91IGhhdmUgYSBwcm9kdWN0IHRoYXQgaXMgZXhwZWN0
ZWQgdG8gZXZvbHZlPGJyPg0Kb3ZlciB5ZWFycyBvciBzb21ldGhpbmcgZGVzaWduZWQgdG8gYmUg
c29sZCBhbmQgdGhyb3duIGF3YXk8YnI+DQphZnRlcndhcmRzLiA7LSk8YnI+DQo8YnI+DQovanM8
YnI+DQo8YnI+DQpQUzogSSBoYXZlIGp1c3QgaW1wbGVtZW50ZWQgYSBZQU5HIGRhdGEgbW9kZWwg
J21hbnVhbGx5JyBiZWNhdXNlIEkgaGFkPGJyPg0KJm5ic3A7ICZuYnNwOyByZWFzb25zIHRvIG5v
dCBkZXBlbmQgb24gdG9vbCBjaGFpbnMgKHRoZSB0YXJnZXQgZW52aXJvbm1lbnQgYXJlPGJyPg0K
Jm5ic3A7ICZuYnNwOyBPcGVuV3J0IHR5cGUgb2YgZGV2aWNlcykuIEJ1dCBzdGlsbCBJIHRvb2sg
YWR2YW50YWdlIG9mIGhhdmluZzxicj4NCiZuYnNwOyAmbmJzcDsgWUFORyB0b29scyBhdmFpbGFi
bGUgdG8gdmFsaWRhdGUgdGVzdCBjYXNlcyBzbyB0aGF0IEkgY2FuIGJlPGJyPg0KJm5ic3A7ICZu
YnNwOyByZWFzb25hYmx5IHN1cmUgbXkgbWFudWFsbHkgd3JpdHRlbiBjb2RlIGlzIGEgZ29vZCBt
YXRjaCBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7IGNvbnRyYWN0LjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUg
Y29tbWVyY2lhbCBhbmQgb3Blbi1zb3VyY2UgdG9vbGNoYWlucyB0aGF0IGhhbmRsZSB0aGUgTkVU
Q09ORi9ZQU5HPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5pbnRlcmFjdGlvbiBtb2RlbCBhbmQgbW9zdCBvZiB0aGUgZGF0YSBtb2RlbCBkZXRhaWxz
IGluIHRoZSBwcm90b2NvbCBzdGFjaywgaW5zdGVhZCBvZiBwdXNoaW5nIHRoYXQ8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndvcmsgb3V0IHRvIHRo
ZSBtb2RlbCBpbnN0cnVtZW50YXRpb24uJm5ic3A7IFRoaXMgY2FuIHNhdmUgYSBsb3Qgb2YgY29k
ZSBhbmQgbWFrZXMgc3VyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+dGhlIGNsaWVudCBvciBzZXJ2ZXIgaGFzIGNvbnNpc3RlbnQgYmVoYXZpb3Iu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1
dCB5b3UgYXJlIG1ha2luZyBhbiBpbXBvcnRhbnQgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZXhwZWN0ZWQgdXNlIENvTUkvQ29P
TCBjby1hdXRob3JzIGhhdmUgZGlzY3Vzc2VkIGlzIGNsaWVudCBmaXJtd2FyZSB3cml0dGVuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byB3b3Jr
IHdpdGggc3BlY2lmaWMgWUFORyBtb2R1bGVzL3JldmlzaW9ucy4mbmJzcDsgVGhlIGNsaWVudCBu
ZWVkcyB0byByZXRyaWV2ZSBlbm91Z2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPnNlcnZlciBzdGF0ZSB0byBrbm93IGlmIHRoZSBzZXJ2ZXIgc3Vw
cG9ydHMgdGhlIHNhbWUgbW9kdWxlIHJldmlzaW9ucywgYW5kIHRoZW4ganVzdCBhc3N1bWVzPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgQVBJ
IGNvbnRyYWN0IHdpbGwgYmUgZm9sbG93ZWQuJm5ic3A7IEl0IGRvZXMgbm90IG5lZWQgYW55IFlB
TkcgcGFyc2VyIG9yIGNvZGUgYXV0b21hdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFzcz0i
aG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS08L3NwYW4+PC9zcGFuPjxzcGFu
IHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5KdWVyZ2Vu
IFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ph
Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9l
bnpiIj5QaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8L3NwYW4+PGJy
Pg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAg
MzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PC9zcGFuPjwvc3Bhbj48
YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPjxzcGFuIGNsYXNzPSJob2VuemIi
PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mZ3Q7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5k
eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9Imhv
ZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Y29yZSBtYWlsaW5nIGxpc3Q8L3Nw
YW4+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYu
b3JnPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9v
OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBv
ZiB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl
IGludGVuZGVkIHJlY2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2Vk
IGJ5IG9yIGNvcGllZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQuIElmDQogdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFz
ZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5k
IGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIg
bm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZp
cnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvcg0KIG90aGVyd2lz
ZSBjaGVjayB0aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_--

--_004_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_
Content-Type: application/octet-stream; name="IPSO_Object-Presence.yang"
Content-Description: IPSO_Object-Presence.yang
Content-Disposition: attachment; filename="IPSO_Object-Presence.yang";
	size=1553; creation-date="Fri, 22 Apr 2016 08:07:14 GMT";
	modification-date="Fri, 22 Apr 2016 08:33:38 GMT"
Content-Transfer-Encoding: base64

bW9kdWxlIElQU09fT2JqZWN0LVByZXNlbmNlIHsNCgkvLyBoZWFkZXIgaW5mb3JtYXRpb24NCgl5
YW5nLXZlcnNpb24gIjEiOw0KCW5hbWVzcGFjZSAidXJuOm9tYTpsd20ybTpleHQ6MzMwMiI7DQoJ
cHJlZml4ICJJUFNPX09iamVjdC1QcmVzZW5jZSI7DQoJDQoJLy8gbWV0YSBpbmZvcm1hdGlvbg0K
CWNvbnRhY3QgIkRvbWluaWsgVm9ndCA8RG9taW5pay5Wb2d0QHRyaWRvbmljLmNvbT4iOw0KCWRl
c2NyaXB0aW9uDQoJCSJUaGlzIGlzIGFuIGV4YW1wbGUgb2YgYW4gSVBTTyBPYmplY3QgbW9kZWxl
ZCBpbiBZQU5HLg0KCQkNCgkJRGVzY3JpcHRpb246IFRoaXMgSVBTTyBvYmplY3Qgc2hvdWxkIGJl
IHVzZWQgd2l0aCBhIHByZXNlbmNlIHNlbnNvciB0byByZXBvcnQgcHJlc2VuY2UgZGV0ZWN0aW9u
LiBJdCBhbHNvIHByb3ZpZGVzIHJlc291cmNlcyB0byBtYW5hZ2UgYSBjb3VudGVyLCB0aGUgdHlw
ZSBvZiBzZW5zb3IgdXNlZCAoZS5nIHRoZSB0ZWNobm9sb2d5IG9mIHRoZSBwcm9iZSksIGFuZCBj
b25maWd1cmF0aW9uIGZvciB0aGUgZGVsYXkgYmV0d2VlbiBidXN5IGFuZCBjbGVhciBkZXRlY3Rp
b24gc3RhdGUuIjsNCglyZWZlcmVuY2UgIklQU08gU21hcnQgT2JqZWN0IEd1aWRlbGluZTogaHR0
cDovL3d3d24uaXBzby1hbGxpYW5jZS5vcmcvc28tc3RhcnRlci1wYWNrIjsNCgkNCgkvLyBkYXRh
IHN0YXRlbWVudHMNCglsZWFmIERpZ2l0YWxfSW5wdXRfU3RhdGUgew0KCQl0eXBlIGJvb2xlYW47
DQoJCWRlZmF1bHQgZmFsc2U7DQoJCWNvbmZpZyBmYWxzZTsNCgkJZGVzY3JpcHRpb24gIlRoZSBj
dXJyZW50IHN0YXRlIG9mIHRoZSBwcmVzZW5jZSBzZW5zb3IiOw0KCX0NCgkNCglsZWFmIERpZ2l0
YWxfSW5wdXRfQ291bnRlciB7DQoJCXR5cGUgdWludDE2Ow0KCQlkZWZhdWx0IDA7DQoJCWNvbmZp
ZyBmYWxzZTsNCgkJZGVzY3JpcHRpb24gIlRoZSBjdW11bGF0aXZlIHZhbHVlIG9mIGFjdGl2ZSBz
dGF0ZSBkZXRlY3RlZC4iOw0KCX0NCgkNCglsZWFmIFNlbnNvcl9UeXBlIHsNCgkJdHlwZSBzdHJp
bmc7DQoJCWRlZmF1bHQgIlBJUiI7DQoJCWNvbmZpZyBmYWxzZTsNCgkJZGVzY3JpcHRpb24gIlRo
ZSB0eXBlIG9mIHRoZSBzZW5zb3IsIGZvciBpbnN0YW5jZSBQSVIgdHlwZSI7DQoJfQ0KCQ0KCWxl
YWYgQnVzeV90b19DbGVhcl9kZWxheSB7DQoJCXR5cGUgdWludDE2Ow0KCQl1bml0cyAibXMiOw0K
CQlkZWZhdWx0ICIxMDAwMCI7DQoJCWRlc2NyaXB0aW9uICJEZWxheSBmcm9tIHRoZSBkZXRlY3Rp
b24gc3RhdGUgdG8gdGhlIGNsZWFyIHN0YXRlIGluIG1zIjsNCgl9DQoJDQoJbGVhZiBDbGVhcl90
b19CdXN5X2RlbGF5IHsNCgkJdHlwZSB1aW50MTY7DQoJCXVuaXRzICJtcyI7DQoJCWRlZmF1bHQg
IjAiOw0KCQlkZXNjcmlwdGlvbiAiRGVsYXkgZnJvbSB0aGUgY2xlYXIgc3RhdGUgdG8gdGhlIGJ1
c3kgc3RhdGUgaW4gbXMiOw0KCX0NCgkNCgkvLyBycGMgc3RhdGVtZW50cw0KCXJwYyBEaWdpdGFs
X0lucHV0X0NvdW50ZXJfUmVzZXQgew0KCQlkZXNjcmlwdGlvbiAiUmVzZXQgdGhlIENvdW50ZXIg
dmFsdWUiOw0KCX0NCn0=

--_004_VI1PR06MB1839CAEC8A9D774D92F3EDB6FC6F0VI1PR06MB1839eurp_--


From nobody Fri Apr 22 02:05:54 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7712EA6B for ; Fri, 22 Apr 2016 02:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 GOZXjBBpzrRf for ; Fri, 22 Apr 2016 02:05:49 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2AB12EA77 for ; Fri, 22 Apr 2016 02:05:44 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 902461014; Fri, 22 Apr 2016 11:05:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bagUMwUk53MK; Fri, 22 Apr 2016 11:05:21 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 22 Apr 2016 11:05:42 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 307C820046; Fri, 22 Apr 2016 11:05:42 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cH_tn2LLdg87; Fri, 22 Apr 2016 11:05:40 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 639372004A; Fri, 22 Apr 2016 11:05:39 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5D5B43AAEDCA; Fri, 22 Apr 2016 11:05:38 +0200 (CEST)
Date: Fri, 22 Apr 2016 11:05:38 +0200
From: Juergen Schoenwaelder 
To: Somaraju Abhinav 
Message-ID: <20160422090538.GA10739@elstar.local>
Mail-Followup-To: Somaraju Abhinav , Andy Bierman , Michel Veillette , Hannes Tschofenig , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>  <20160421213738.GD8993@elstar.local>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of	draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 09:05:52 -0000

We have modeled something in YANG is not the same as there is a
_simple_ translation (or I wrongly assumed 'automated translation'
while the intention was 'human translation'?).

The link you provide still requires to register my email address, but
yes this time with a bit less legalize. Anyway, I am not interested in
looking at stuff where content protection is apparently rated higher
than open access.

Concerning operations: In YANG 1.1, you can associate an operation
with a YANG container or a YANG list element (it is called an action
in YANG 1.1). But since you map so called 'objects' to modules, it
probably does not matter (and I am not sure mapping 'objects' to
modules is what I would do but then I just do not the LWM2M details).

/js

On Fri, Apr 22, 2016 at 08:46:50AM +0000, Somaraju Abhinav wrote:
> Hi,
> We have been using YANG to model objects that we use with LWM2M for about 6 months now. As far as I can tell, there is only one part of the LWM2M resource model that cannot be modelled using YANG: LWM2M has resources on which you can read, write and execute (operations). YANG distinguishes between resources that are operations vs data and therefore cannot be used to model resources in LWM2M that support the three types of operations. There are of course ways around this issue.
> 
> As an example, please find attached an IPSO object available for download at http://www.ipso-alliance.org/so-starter-pack/ which my colleague has modelled in YANG. Please note that the YANG model is just an example and is not approved/endorsed by IPSO or LWM2M.
> 
> Regards,
> Abhinav
> 
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Donnerstag, 21. April 2016 23:50
> To: Juergen Schoenwaelder ; Michel Veillette ; Hannes Tschofenig ; core@ietf.org WG 
> Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
> 
> 
> 
> On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder > wrote:
> On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Veillette wrote:
> > Hi Juergen
> >
> > The extract I have provided is from a publically available document, see:
> > https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf
> >
> > My remark about the LWM2M modeling language was just to highlight that such language don't necessary imply code generation.
> >
> 
> YANG does not imply code generation either. A YANG module defines a
> contract, and in the light of a protocol a programmatic interface.
> There is nothing in YANG that requires code generation.
> 
> It just happens that people often tend to automate things if they find
> themself repeatedly writing similar code. It is at the end a question
> of how much data a device exposes and what kind of developers you are
> dealing with and whether you have a product that is expected to evolve
> over years or something designed to be sold and thrown away
> afterwards. ;-)
> 
> /js
> 
> PS: I have just implemented a YANG data model 'manually' because I had
>     reasons to not depend on tool chains (the target environment are
>     OpenWrt type of devices). But still I took advantage of having
>     YANG tools available to validate test cases so that I can be
>     reasonably sure my manually written code is a good match of the
>     contract.
> 
> 
> There are commercial and open-source toolchains that handle the NETCONF/YANG
> interaction model and most of the data model details in the protocol stack, instead of pushing that
> work out to the model instrumentation.  This can save a lot of code and makes sure
> the client or server has consistent behavior.
> 
> But you are making an important point.
> The expected use CoMI/CoOL co-authors have discussed is client firmware written
> to work with specific YANG modules/revisions.  The client needs to retrieve enough
> server state to know if the server supports the same module revisions, and then just assumes
> the API contract will be followed.  It does not need any YANG parser or code automation.
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 
> 
> Andy
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 
> ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Apr 22 02:15:25 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FF312EAAC for ; Fri, 22 Apr 2016 02:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8IOYA4wgc8z for ; Fri, 22 Apr 2016 02:15:22 -0700 (PDT)
Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id BB41112EAB2 for ; Fri, 22 Apr 2016 02:15:22 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id B84982AC03F; Fri, 22 Apr 2016 11:13:39 +0200 (CEST)
X-Originating-IP: 134.102.91.1
Received: from eduroam-pool10-258.wlan.uni-bremen.de (eduroam-pool10-258.wlan.uni-bremen.de [134.102.91.1]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D8D45C5A68; Fri, 22 Apr 2016 11:13:37 +0200 (CEST)
Message-ID: <5719EB3F.4050301@tzi.org>
Date: Fri, 22 Apr 2016 11:13:35 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Somaraju Abhinav ,  Andy Bierman , Michel Veillette ,  Hannes Tschofenig , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>  <20160421213738.GD8993@elstar.local>   <20160422090538.GA10739@elstar.local>
In-Reply-To: <20160422090538.GA10739@elstar.local>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [core] ? WG adoption of	draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 09:15:24 -0000

That registration process also appears to be broken.

https://open-stand.org

Grüße, Carsten


Juergen Schoenwaelder wrote:
> The link you provide still requires to register my email address, but
> yes this time with a bit less legalize. Anyway, I am not interested in
> looking at stuff where content protection is apparently rated higher
> than open access.


From nobody Fri Apr 22 03:25:43 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A379C12D9E2 for ; Fri, 22 Apr 2016 03:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 6ljfeOgf-R8d for ; Fri, 22 Apr 2016 03:25:39 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C669712D8C6 for ; Fri, 22 Apr 2016 03:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com;  s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7N86N4327ZRYPJnh/3HYOrctWp9boVN2EbvyqdKQf3U=; b=IsU5eCN0E2epEuQ2s5FUWW3kMhgNy6h1IolkwjUyiaWxx7SAaEbxTdsO8s3ZKJfjcTbjicWhDyf4tsM/KHUHn1B2jQ6ZwQJ7M0oy7cU2r+hMIC3eKB6aDDeQ3Ck//nyQxq0dItejXIuuci5qFk+VWLY4sDlQWT7vDq4xkMN0rSQ=
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1840.eurprd06.prod.outlook.com (10.165.237.158) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 10:25:17 +0000
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0466.023; Fri, 22 Apr 2016 10:25:17 +0000
From: Somaraju Abhinav 
To: Juergen Schoenwaelder 
Thread-Topic: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
Thread-Index: AQHRm/X+5ubwG7D3zkGKYQfJYUlSTp+U1XaAgAAQYQCAAAPogIAACmYAgAADbQCAALSEcIAACEQAgAASJFA=
Date: Fri, 22 Apr 2016 10:25:16 +0000
Message-ID: 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>  <20160421204630.GA8993@elstar.local>  <20160421213738.GD8993@elstar.local>   <20160422090538.GA10739@elstar.local>
In-Reply-To: <20160422090538.GA10739@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=tridonic.com;
x-originating-ip: [146.108.200.10]
x-ms-office365-filtering-correlation-id: ac4eae3b-53c7-4bb2-ef95-08d36a98661b
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1840; 5:3pw9Bl2O5XIHuCLOycHdKk2sDu73zNzd5mVS86hcwk7BraH/iwoIpQvfo0nyGh81mQ98QW+N0ZA73oKmpopORdCJ4M5U8gWyywVet2eOrHhglt0gkvLX32ZceWjUplutWvPi15QCSnI+GmFEiJWv+dO+v4v7wOaQeSBZC22R9Lam3acGSCBBoCS2+Yk4kO0f; 24:HrCucksR9GBwdxZW35BOrYTrRjeMgT3JHiQwA5ql/lHTMDRv/iu5cTSYs8EOugCXTcaMjSbxTiRK/fPIlNh4XJYGIbPbpoOlqhwFvkYK9cs=; 7:MzBk8y71+pMcQ2jlKcroEIeW96CCuSSUv+ABduFfFvKM0+oSRo/72eAUtLQu5LUIVwY5ozTW0A0EBJcUTYpa1ik3kjS5QI0jdrcIbZdRPWpGu2/fgy+0v4n5sWGejNkUB8eJ762QoiPNIExLrqohKxoZ/M9MIFwRLWZQDIeKv/YbjQmwESnPqDesNr2r2mvEasahbxfZvPKh8rJYJZ5sHWn6HmHxeZDJNvYh1xQnYIY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1840;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR06MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1840; 
x-forefront-prvs: 0920602B08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(19580395003)(2950100001)(5890100001)(77096005)(15975445007)(87936001)(76576001)(19580405001)(50986999)(5004730100002)(76176999)(54356999)(230783001)(2900100001)(586003)(122556002)(106116001)(5003600100002)(86362001)(11100500001)(93886004)(5002640100001)(74316001)(1220700001)(3660700001)(9686002)(4326007)(10400500002)(189998001)(2906002)(3280700002)(1096002)(66066001)(33656002)(5008740100001)(92566002)(3846002)(81166005)(102836003)(6116002)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1840; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: tridonic.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2016 10:25:16.8333 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1840
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of	draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 10:25:41 -0000

We have modeled something in YANG is not the same as there is a _simple_ tr=
anslation (or I wrongly assumed 'automated translation'
while the intention was 'human translation'?).
[AS] Agree. This was just supposed to be an example. We have not worked on =
a translation tool/rules from YANG to LWM2M. However, we do use automated t=
ools to go from YANG modules to LWM2M compliant client code-skeletons writt=
en in c/c++ (via an intermediate and unnecessary step of producing XSD file=
s).

Concerning operations: In YANG 1.1, you can associate an operation with a Y=
ANG container or a YANG list element (it is called an action in YANG 1.1).
[AS] Yes, we looked at using containers+actions to model read/write/execute=
 resources. I think there are a few ways to do this - e.g. using Yang exten=
sions. I have personally not had to use it though because I prefer the YANG=
 solution of keeping data and operations separate.

But since you map so called 'objects' to modules, it probably does not matt=
er (and I am not sure mapping 'objects' to modules is what I would do but t=
hen I just do not the LWM2M details).
[AS] I played around with three options initially - using YANG submodules a=
s LWM2M objects, using YANG containers as objects and using YANG modules as=
 objects. For our purpose all three options worked okay. I don't have a pre=
ference one way or another.


On Fri, Apr 22, 2016 at 08:46:50AM +0000, Somaraju Abhinav wrote:
> Hi,
> We have been using YANG to model objects that we use with LWM2M for about=
 6 months now. As far as I can tell, there is only one part of the LWM2M re=
source model that cannot be modelled using YANG: LWM2M has resources on whi=
ch you can read, write and execute (operations). YANG distinguishes between=
 resources that are operations vs data and therefore cannot be used to mode=
l resources in LWM2M that support the three types of operations. There are =
of course ways around this issue.
>
> As an example, please find attached an IPSO object available for download=
 at http://www.ipso-alliance.org/so-starter-pack/ which my colleague has mo=
delled in YANG. Please note that the YANG model is just an example and is n=
ot approved/endorsed by IPSO or LWM2M.
>
> Regards,
> Abhinav
>
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Donnerstag, 21. April 2016 23:50
> To: Juergen Schoenwaelder ;
> Michel Veillette ; Hannes
> Tschofenig ; core@ietf.org WG
> 
> Subject: Re: [core] ? WG adoption of
> draft-veillette-core-yang-cbor-mapping-00
>
>
>
> On Thu, Apr 21, 2016 at 2:37 PM, Juergen Schoenwaelder > wrote:
> On Thu, Apr 21, 2016 at 09:00:29PM +0000, Michel Veillette wrote:
> > Hi Juergen
> >
> > The extract I have provided is from a publically available document, se=
e:
> > https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf
> >
> > My remark about the LWM2M modeling language was just to highlight that =
such language don't necessary imply code generation.
> >
>
> YANG does not imply code generation either. A YANG module defines a
> contract, and in the light of a protocol a programmatic interface.
> There is nothing in YANG that requires code generation.
>
> It just happens that people often tend to automate things if they find
> themself repeatedly writing similar code. It is at the end a question
> of how much data a device exposes and what kind of developers you are
> dealing with and whether you have a product that is expected to evolve
> over years or something designed to be sold and thrown away
> afterwards. ;-)
>
> /js
>
> PS: I have just implemented a YANG data model 'manually' because I had
>     reasons to not depend on tool chains (the target environment are
>     OpenWrt type of devices). But still I took advantage of having
>     YANG tools available to validate test cases so that I can be
>     reasonably sure my manually written code is a good match of the
>     contract.
>
>
> There are commercial and open-source toolchains that handle the
> NETCONF/YANG interaction model and most of the data model details in
> the protocol stack, instead of pushing that work out to the model
> instrumentation.  This can save a lot of code and makes sure the client o=
r server has consistent behavior.
>
> But you are making an important point.
> The expected use CoMI/CoOL co-authors have discussed is client
> firmware written to work with specific YANG modules/revisions.  The
> client needs to retrieve enough server state to know if the server
> supports the same module revisions, and then just assumes the API contrac=
t will be followed.  It does not need any YANG parser or code automation.
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
>
> Andy
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
> ________________________________________________________ The contents of =
this e-mail and any attachments are confidential to the intended recipient.=
 They may not be disclosed to or used by or copied in any way by anyone oth=
er than the intended recipient. If this e-mail is received in error, please=
 immediately notify the sender and delete the e-mail and attached documents=
. Please note that neither the sender nor the sender's company accept any r=
esponsibility for viruses and it is your responsibility to scan or otherwis=
e check this e-mail and any attachments.



--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         
________________________________________________________ The contents of th=
is e-mail and any attachments are confidential to the intended recipient. T=
hey may not be disclosed to or used by or copied in any way by anyone other=
 than the intended recipient. If this e-mail is received in error, please i=
mmediately notify the sender and delete the e-mail and attached documents. =
Please note that neither the sender nor the sender's company accept any res=
ponsibility for viruses and it is your responsibility to scan or otherwise =
check this e-mail and any attachments.


From nobody Fri Apr 22 05:13:02 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78A012DC61 for ; Fri, 22 Apr 2016 05:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMHNekMP92-f for ; Fri, 22 Apr 2016 05:12:59 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0122.outbound.protection.outlook.com [104.47.1.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CD912D63A for ; Fri, 22 Apr 2016 05:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yT7brXfJ9eJmqXCgWR99NZGUIx4sI6+CoLygC68OxVs=; b=JMss3dS6885l5CXUaLFuO05vtEbStkFD3trF1DCo2+aciHp89jDWdGUcbLjvGMn+nPn86bBXY7JZvJJYxQD2TGCdNtScMGq4Gbe6N5UX7g/7bVbOxwT9kaL0EdSrMKl/ABltIma66N3zviIQnVeBSpdkss8aI99zkty6gWTofGg=
Received: from AM3PR04CA0116.eurprd04.prod.outlook.com (10.163.180.170) by DB4PR04MB363.eurprd04.prod.outlook.com (10.141.236.151) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 22 Apr 2016 12:12:56 +0000
Received: from AM1FFO11OLC004.protection.gbl (2a01:111:f400:7e00::176) by AM3PR04CA0116.outlook.office365.com (2a01:111:e400:5366::42) with Microsoft SMTP Server (TLS) id 15.1.466.19 via Frontend Transport; Fri, 22 Apr 2016 12:12:55 +0000
Authentication-Results: spf=none (sender IP is 23.103.247.132) smtp.mailfrom=philips.com; tcs.com; dkim=none (message not signed) header.d=none;tcs.com; dmarc=none action=none header.from=philips.com;
Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts)
Received: from 011-smtp-out.Philips.com (23.103.247.132) by AM1FFO11OLC004.mail.protection.outlook.com (10.174.65.79) with Microsoft SMTP Server (TLS) id 15.1.472.8 via Frontend Transport; Fri, 22 Apr 2016 12:12:55 +0000
Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com (141.251.190.18) by HE1PR9001MB0172.MGDPHG.emi.philips.com (141.251.190.20) with Microsoft SMTP Server (TLS) id 15.1.453.26; Fri, 22 Apr 2016 12:12:54 +0000
Received: from HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) by HE1PR9001MB0170.MGDPHG.emi.philips.com ([141.251.190.18]) with mapi id 15.01.0453.032; Fri, 22 Apr 2016 12:12:54 +0000
From: "Dijk, Esko" 
To: Abhijan Bhattacharyya 
Thread-Topic: Using draft-tcs-coap-no-response-option to *enable* responses
Thread-Index: AdGcj/YQCrN+XzqqSpmFRQBEAJ7w2A==
Date: Fri, 22 Apr 2016 12:12:54 +0000
Message-ID: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [83.85.132.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:23.103.247.132; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(428002)(189002)(199003)(85714005)(374574003)(6806005)(33646002)(92566002)(5003600100002)(3846002)(5004730100002)(11100500001)(50466002)(105586002)(97756001)(101416001)(2900100001)(108616004)(230783001)(5008740100001)(106466001)(54356999)(1096002)(1220700001)(46406003)(229853001)(102836003)(50986999)(189998001)(23726003)(4326007)(6116002)(81166005)(66066001)(47776003)(2906002)(110136002)(86362001)(87936001)(24736003)(16796002)(10400500002)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR04MB363; H:011-smtp-out.Philips.com; FPR:;  SPF:None; MLV:sfv; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11OLC004; 1:BVMcJ4KME6HF+JtAasDWHQB0VhE6oJ3f3PAwUNr6GtdJ5HtatJk8BuDVT+L/473RAsyoobGm0GLY3iyH8HUrkFZf4ifzQY5ZJW7QWP3f4fsS7i5s3vmJOoW0MdKEb2d/TUPi3Hnl2ai/47jYeG1oJ+Mk9s+/4iXIBDTDymMNltoyt0QVPAQME5m3dBaC0u0slxPa4Lf+2rNZJZCxkKkloRabd3ToxUSdrqxali02ZEEGSYpezsdtXYJu9cjjbofYtpF9bxU8u0zIL9qZE6DdaWgAcjubH+kM15tGCc5DBPJqRRki0cRoqXnKynT01Mj5dtNkfolwc5lUgKEnD580Ier2E8nnyEG90hAtWDwHDVkgL6Bgn7SKiykKDqeuF9UmC/MpZdGI6ryCHvyyLfIUnLwtrXmC95HHdbbTGAuXIsNahLDfoAjDqYXNiaLdIvzE
X-MS-Office365-Filtering-Correlation-Id: 2452d598-72e9-44e8-5dcd-08d36aa76ff0
X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 2:qC41d66u3BrsWH0eq51dsXXjPW4Cg8Hvs7uFEDikPz5KF9JeDTd9rli0sRw9IvAWHoJUmM6+3GFayNTOrasePXr19tnb9sRKMSiDDlRQu5y7H2yuRoXxbyAj1fnPSKigtlWeCATZQ+m9p3nUI3x8BD+54gueBFTG88OfJEDkghMqxy5BdY2NiA+ny6TfSjk7; 3:q3ctGjl19UejstBLKEVftVAaLs0KG67tMdzA/6IgamxlZLgf6AYrjDSanFpipAnUHnoMU0SFMuW/l9qk0yjp+sJ2EHfLIbI4zoLbcAgQVPegfFxIZK7me1E0bo5J0B+dE36GoKjSe9jvHR8wDusbq3c478yeEv+LgEq9ySE3ugGuScF1yEQdLpgOYMg83WCO4TZ/1uGFFsJFPRaGFGurWQvDA4P6O6DIwUXcCMVPFSM=; 25:dZTO6y9DReu+RIlTf4rJlw2cqjV3XnvGojpyXLX7+hvkfzRXZF9E0GD0ziOw8xiL6/UBb4+D/Dhq04t+M6JlBiMr7z0ubt6ZQLUFjKRFsqdjnaJQYpNDrSL7WrsLkb7RT/TM02B/qRjnNRc4+i23V1V/4fYDC8aYUiZnAZGSqBQJa3Ma9lUZ7QV/UQ6GKnmK1eBf/5Odv/0mrnByWeQupMtiFqNwy8ZMslgw3Z2TqFj1fRw3xhOtZ3SBKHMIN6EPOqQhKxaFisISBmSWRKSbrzn0PulvTClQphHLzxgztAjzoKo4Uv2++fSk8Nt7lSJf3uzT7hvSKCwpl5e63RPzcA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR04MB363;
X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 20:naS7Cllk4hM9R7S8XH5BYaqvO5WOhvPKST6bDPQ0SfvNgL5Q6hGmbwFRYGIIePW3sSBjAlCbn1Ip7s2MyylamHuoyyz4Ji7ywtzyK27+nHBPDcEyzt5pxOXPtjIWBkbC9eYEwSy15/adZmwlpCKrIpUS/FzNRr5BWvllu86yVy6rsVC1Gl9Cp6F7HhfzugiuXCtvhkrUSJi/viavEhHjIjA0Y2dyxtRgK/UIFURo6+30+9ZSY2QzS0wCi/eucUb9WvAIPRmsxqTHO6mfHKD97+JEs4AX04m5WxURG9Uy4J+eYh33nqX9XbP/JX11wUxHL0mC4dzQHwHLeYsu6ckeQD2ohfVdO3bVSj1OOCWywWpE/9aSBbjuzV8RaKFHB71Lc+3J97aBriSdlXfenw5IblR1C6jTpifa6uV8lloZODKg7CQTYIUK760lrJgGEzeQvoaK5Fc/Onx5r5wG6PlskiGZWGB4Ho5NFyTckkTgxVZhKOepTyPxlqcPr9lK649L
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(13018025)(13016025)(10201501046)(3002001)(6055026); SRVR:DB4PR04MB363; BCL:0; PCL:0; RULEID:; SRVR:DB4PR04MB363; 
X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 4:bL8+RKXRtrG9av5eoqLyPJfGT8iPYAJtF6rSe5+oGClBIGmVFbLoGqOOxHaElagtfet+romHmHdMuJEEQaCoc8PTLfsW6y+bhYh6rvLpBQQwu2rJbhHi+zu3BcQ/VmElRp5KCcFopRmE/KBpSNBQqjQghl9Hf2t6JSoW1dC0IxYOQ32cIw6qhdh2QLj19hamj65kC7btlUEZDRECPuTkb2JOV2KA95Oo5XReBgxQc0vCyuZayEyyl7UlCBzyJ9xxf7DOCUmAPzeutU74y+Dd2jQOVxPDaZs+v1VxoAdb74BhH2en+uttrvP2UkaoqGMaFLzJV9JAxDK+DXzhsyS4zq6vkf4oB872767EejH+VdjRbgADvznnoJXszf0DCiroDIkHY8YZLWPV7u5UkAt1sqJHIE9hPCUfnZ4Q21Yw0rlUAvshctaQ6oihMPcigfbABSxqgL24GnKEb/Jj2yt13w==
X-Forefront-PRVS: 0920602B08
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR04MB363; 23:Dv920RQQZc0HceNmlc1fp/RW+CwK/7qQ9zdkni2e/A?= =?us-ascii?Q?ya+6mkllXWuB8qCZ+C2+7bZL7fvN8VVJHHpWC/M+M2db0zGkRfbLjMNyLzIh?= =?us-ascii?Q?qiypz0ObOpjWrQ8MzkNmeDWadfN2mQuey/tLNwHCKHqzSAVyd/w49/sb8443?= =?us-ascii?Q?om1rYGRneM/99ICnawpu3JO6MAGucnNgfYkhFAbU/51FyQdo4eknpmnYllP9?= =?us-ascii?Q?rAUu9+XPdHlARhJ5hX7BDH0tBAfbi3dlLeRUoVyezlIjzDXtAHRrOP+4Ln+P?= =?us-ascii?Q?uA2K3wdqUV9z4wKyMDzLJ/nsv4h4a2GMy4mn0nhv5X1pmvbzec/h8ia9Syrr?= =?us-ascii?Q?4yYWLKdA7V2sI8cIFYsx7vJbvxj5ZluJPSwMXU607oIA5bIuys6rn+60fzXB?= =?us-ascii?Q?GIC4TC9hmrIvo4Pil/OJRvyIE2ygIUWlC/QKHFWD7fncPDIY+8I5lBnkwXBa?= =?us-ascii?Q?QWyJ+EpMTlMw6ac+QRLDJtv41+aH5GTVrKymYlAqxZteN0cKhZAIxlh8HXLH?= =?us-ascii?Q?DVgyp2ClZRf+RWpjjKFfq7VQTfMu+vZIattAAAvbJUkOEdk9EI44KCJkTaQH?= =?us-ascii?Q?Hc8jlfY+zZPZFFwySqZB3JNDYDdcI8eZti1z2LFVq9usgj1fDY0RIcYA8dyj?= =?us-ascii?Q?R2tfqEZJQW76d0HrKp4Pr2qEC1N/DkwKnPIl77Vn9PM8VMPCREN9D0pF77vL?= =?us-ascii?Q?VSNZCbxlRI1quo4t9HjX8zqMaQhqgbVQsT4e/OtLAeV8N5M9qqpEeQczhkUT?= =?us-ascii?Q?5wNQJkzGWNu+dqc5ZiT5yrB8IQluxVVugnGyEybLu6nJ8idthT4/4YVmHzXx?= =?us-ascii?Q?Bbm2mSD6QOYYsqLodMXu2MAt1qWhw+Yq07XJ8DVIldHtq2ysC4aj1j48Xixj?= =?us-ascii?Q?JrYn7Ykp7oZLuspTKOgMhMSGUHOEB6eRSLXRquZUDVbIvoZ2zf3abLfdVy/2?= =?us-ascii?Q?9oUtG/dR+PyuOJikjaJivtMkHfCDZ1dsh72VZQcD/TbumBKtivLh66pwpi3X?= =?us-ascii?Q?Zs+xMY0hFh/V5yTIAdKDzEhJneZBXE7ut87apQp6uOXJwJccCtln/nBt0E3i?= =?us-ascii?Q?3zbH7HXuhDC/U7Vkt5C4YxOeeXwJSfv+3szMpWeeu36/x1PqKNj6iBRrtzEQ?= =?us-ascii?Q?Qz5YOQWjX0QjbXRxdn51bVc4QOfXoPdtyQ3GglrpkZuBPYwGGeLw=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB4PR04MB363; 5:yXaeJFox4dANfvWszsPVEZsePa1Kg/Wmg2Ud4mSk6vhjdKqEePCiVV8TiHt//fSkrw8oMWyfm9Xr4tX9+5wzZlEFiYO9axp4Ctmzs4SkIme/oZXcMytRoylnpRuSmK3udp7mdBhRy3/tgOf/ZHHbZ8bNQRPwlYPYP1sW6UoHNorHpXL0hvyR1g19frEU/Ca4; 24:EpdQAbPJF1hqxJAA8972YZ2GsRbvsUS+DDhnHR96C/kfiseOlB91YFMHOdV6/qXoLCTsnu6ks/IMFsZL0ZlW9bWNLE+raU7mGphuYDTvVWE=; 7:4tLcMWDDmPACoos7kF4+UnLcewPwBdf7C8Ca87r+TZDTACf38jdkvILsO/7765F+JJBnRlr2HglIOeqK9iW0OHeGF/eDwLoAWNGll9gFBbue+l+DIdq241XLyIIE9Am56Zwu33jGXG826FEgG8hRz4O5E3/zW0hQvfwK46iIdK1TmAlx6o88iOY/fet/GU+bUd7UxhaKTXQJt6WotsV01HLmJH6RB1XlOZLeR38m8dg=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: philips.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2016 12:12:55.8854 (UTC)
X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[23.103.247.132];  Helo=[011-smtp-out.Philips.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB363
Archived-At: 
Cc: "core@ietf.org WG" , Nevil Brownlee 
Subject: [core] Using draft-tcs-coap-no-response-option to *enable* responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 12:13:01 -0000

Hello Abhijan,

in our project we see a clear use case of using the No-Response Option to *=
enable* certain responses that are by default suppressed.  CoAP allows supp=
ression of multicast responses by default, which is what we use for a light=
ing multicast use case. However for diagnostic usage we'd like to enable th=
ese responses again using the No-Response option which is perfectly suited =
for that. However, the draft text currently only talks about suppressing re=
sponses (not enabling).

Hence my request: could we modify/add some text to show that also the optio=
n can be used to enable responses in case where they are normally (by defau=
lt -- server decision) suppressed?
Just to clarify such usage; which is quite useful in my view.

regards
Esko

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From nobody Fri Apr 22 05:14:20 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CB712DC61 for ; Fri, 22 Apr 2016 05:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level: 
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-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 O35dkXYsDo9g for ; Fri, 22 Apr 2016 05:14:17 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D35312DB1A for ; Fri, 22 Apr 2016 05:14:17 -0700 (PDT)
Received: (qmail 14005 invoked from network); 22 Apr 2016 14:07:34 +0200
Received: from p5dec2f05.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.5) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated);  22 Apr 2016 14:07:33 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <57187ABB.7050301@tzi.org>
Date: Fri, 22 Apr 2016 14:07:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <27FCC29F-4D67-4703-B5FD-DC77F4789634@kuehlewind.net>
References: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> <57187ABB.7050301@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org
Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-block-19=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 12:14:18 -0000

Hi Carsten,

see below.

Mirja

> Am 21.04.2016 um 09:01 schrieb Carsten Bormann :
>=20
> Hi Mirja,
>=20
>> =
----------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> This is only a minor point, requesting to spell out implicit =
assumptions
>> explicitly. However, I think it's important to address this before
>> publication.
>>=20
>> It is not clear in the main part of the doc that this extension to =
does
>> not change the message transmission method as specified in RFC7252
>> (Stop-and-wait retransmission). With my initial ready I assumed that =
this
>> extension would allow the sending of back-to-back messages. Only by
>> looking at the examples, it got clear to me that this is not the =
case.=20
>=20
> I'm wondering how we managed to create that expectation.

I guess by not talking about it at all (and Spencer and me being overly =
sensitive to this topic) :-)

>=20
> As I said in the response to Spencer's comment, block-wise transfers =
are
> strictly layered on top of RFC 7252 CoAP.  Maybe there is some
> introductory text needed that emphasizes this early on.

Yes, please add something similar as what you=E2=80=99ve written in your =
response to Spencer, (early) in the doc. Thanks!

>=20
> Implementations that I know run completely lock-step.  Theoretically, =
an
> implementation could pipeline requests for further blocks after the
> initial exchange (which needs to be lock-step so a common block-size =
can
> be determined; also, a Size2 option would be needed to determine the
> number of requests to be sent).  NSTART (Section 4.7 of RFC 7252) puts =
a
> hard limit on the parallelism here, and the default value of NSTART
> (without advanced congestion control) is 1, so we are back to =
lock-step.

Okay, the problem with not talking about this at all is that all these =
value in rfc7252 are only recommendation. There are no restricting max =
values which are defined like 'MUST NOT be larger than X'. Therefore my =
fear would be that people could assume that this extension, as it =
supports sending or larger data, could provide a reason to increase the =
default values.

Would it make sense to say something like: Using this extension MUST NOT =
lead to changes in the transmission behavior (e.g. other default value =
than specified in RFC7252).  ?

>=20
>> Further, this document does not say anything about reliability. Do =
block
>> message need to be transmitted reliable (as Confirmable)? If not, =
this
>> extension could still lead to back-to-back sending and then further
>> guidance on congestion control would be needed.
>=20
> Block-wise transfers can be sent in NON messages.  That would not be a
> particularly wise choice in general, as the delivery probability for =
the
> whole body decreases exponentially (section 2.8 outlines one specific
> use case for using NON in the first block only, though).

Again, I don=E2=80=99t think this is spelled to anywhere and really =
should.

>=20
> NON messages can not simply be sent back-to-back in CoAP, see section
> 4.7 of RFC 7252.

Please correct me if I=E2=80=99m wrong but looking at section 4.7 this =
might not be well enough defined to be fully applicable and save for a =
case where you send a large message with several blocks as NON (even =
though this is in general not recommended). Note, 4.7 is explicitly =
saying "Further congestion control optimizations and considerations are =
expected in the future=E2=80=9C. Please double-check and consider giving =
further recommendations in this doc!

>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> I agree with others that reduncy makes the doc harder to read, =
especially
>> regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs =
and
>> MUST in one section and combine the Usage guidance with the examples?
>=20
> The usage guidance (section 2.5?) is more normative than just an
> example.  Moving all interoperability requirements into one section
> might create even more duplication of text.

Might still be worth trying to remove redundancy where possible and =
double-check all MUST and SHOULD. Thanks!

>=20
>> Further, please also add a reference for ETag in section 2.4.
>=20
> I have added a reference to Section 5.10.6 of RFC 7252 in the editor's
> draft.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20


From nobody Fri Apr 22 08:00:30 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB012DC2A for ; Fri, 22 Apr 2016 08:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.253
X-Spam-Level: 
X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 7mbp9wJNHqvq for ; Fri, 22 Apr 2016 08:00:27 -0700 (PDT)
Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D10412E95C for ; Fri, 22 Apr 2016 08:00:20 -0700 (PDT)
X-ASG-Debug-ID: 1461337218-06daaa1088534b0001-aa7cYp
Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id lAEHUBXyRn4VOoAK (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2016 11:00:18 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Fri, 22 Apr 2016 11:00:17 -0400
From: "Rahman, Akbar" 
To: Hannes Tschofenig , Carsten Bormann 
Thread-Topic: [core] Issue Tracking of Working Group Items
X-ASG-Orig-Subj: RE: [core] Issue Tracking of Working Group Items
Thread-Index: AQHRmjFgn9ouE5jkqEe3HAdxpiHlVp+RgVIA//++k4CAAgPpAIAC1ZPQ
Date: Fri, 22 Apr 2016 15:00:17 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAB0234@NABESITE.InterDigital.com>
References: <57161AFB.5040804@gmx.net> <5716285E.5020100@tzi.org> <36F5869FE31AB24485E5E3222C288E1F5BAAE871@NABESITE.InterDigital.com> <5717A242.7000306@gmx.net>
In-Reply-To: <5717A242.7000306@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.226]
x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252]
X-Barracuda-Start-Time: 1461337218
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 2599
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.28965 Rule breakdown below pts rule name              description ---- ---------------------- --------------------------------------------------
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] Issue Tracking of Working Group Items
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 15:00:29 -0000

Hi Hannes,


>I prefer to have issues added to make sure we know where we are with our w=
ork.

Okay.  We will add it to the tracker shortly.


>Btw, are you the editor of the HTTP-CoAP document? It seems to me that you=
 are at least the most active person on it (whereas some of your co-authors=
 have disappeared from the scene already).

No, we never assigned a formal Editor for the document.  Maybe I may be the=
 most vocal person (occasionally) but most of the other authors are definit=
ely still active in CORE one way or another if you search the Email archive=
s, or check the draft author names of the current list of active drafts, or=
 check the physical attendee list at the F2F meetings.



Best Regards,

Akbar


-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Wednesday, April 20, 2016 11:38 AM
To: Rahman, Akbar ; Carsten Bormann 
Cc: core@ietf.org WG 
Subject: Re: [core] Issue Tracking of Working Group Items

Thanks, Akbar.

I prefer to have issues added to make sure we know where we are with our wo=
rk.

Btw, are you the editor of the HTTP-CoAP document? It seems to me that you =
are at least the most active person on it (whereas some of your co-authors =
have disappeared from the scene already).

Ciao
Hannes

On 04/19/2016 02:56 PM, Rahman, Akbar wrote:
> Hi Carsten/Hannes,
>
>
> For the HTTP-CoAP draft we did send an email shortly after the meeting as=
king the WG list to confirm our decision at the meeting:
>
> https://www.ietf.org/mail-archive/web/core/current/msg07035.html
>
>
> So I think no tracker ticket is required for this (though we could add on=
e if you think it necessary).
>
>
>
> /Akbar
>
>
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: Tuesday, April 19, 2016 8:45 AM
> To: Hannes Tschofenig 
> Cc: core@ietf.org WG 
> Subject: Re: [core] Issue Tracking of Working Group Items
>
> Hi Hannes,
>
> after an IETF it typically takes a while for people to come back up to sp=
eed, because of significant travel times, combined with a backlog of non-IE=
TF issues waiting at home.  Not all contributors are full time IETFers.
>
> That said, I do indeed request the respective authors to act on trackeriz=
ing the issues by the end of this week.
>
> Gr=FC=DFe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>


From nobody Fri Apr 22 08:16:55 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5312E178 for ; Fri, 22 Apr 2016 08:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 YNdIXsG0Fa7u for ; Fri, 22 Apr 2016 08:16:51 -0700 (PDT)
Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 424E312DEB4 for ; Fri, 22 Apr 2016 08:16:49 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2DPAQCwPRpX/wQXEqxegmyBH326BgENgXMXAQyFagKBXxQBAQEBAQEBgQyEQQEBAQRuCxALBwYEAwECKAdGCQgGCwgbiB2tLAEBAZFqAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYR4Z4UNhCABAQUjFQ0JghJLGIIrBY5GiUmBVYoHhB4XhDaIXY8vHgEBhDVkAYdBgTUBAQE
X-IPAS-Result: A2DPAQCwPRpX/wQXEqxegmyBH326BgENgXMXAQyFagKBXxQBAQEBAQEBgQyEQQEBAQRuCxALBwYEAwECKAdGCQgGCwgbiB2tLAEBAZFqAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYR4Z4UNhCABAQUjFQ0JghJLGIIrBY5GiUmBVYoHhB4XhDaIXY8vHgEBhDVkAYdBgTUBAQE
X-IronPort-AV: E=Sophos;i="5.24,517,1454956200"; d="scan'208";a="76966849"
In-Reply-To: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com>
References: <3c1e2750c7ac4d2b98509e3446d122dd@HE1PR9001MB0170.MGDPHG.emi.philips.com>
To: "Dijk, Esko" 
MIME-Version: 1.0
X-KeepSent: CFA8A8D6:870A6124-65257F9D:004F040B; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0 March 08, 2013
Message-ID: 
From: Abhijan Bhattacharyya 
Date: Fri, 22 Apr 2016 20:46:42 +0530
X-MIMETrack: Serialize by Router on INKOLM102/TCS(Release 9.0.1FP4HF942 | April 13, 2016) at 04/22/2016 20:46:45, Serialize complete at 04/22/2016 20:46:45
Content-Type: multipart/alternative; boundary="=_alternative 0053ED7665257F9D_="
Archived-At: 
Cc: Nevil Brownlee , "core@ietf.org WG" 
Subject: Re: [core] Using draft-tcs-coap-no-response-option to *enable* responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Apr 2016 15:16:53 -0000

This is a multipart message in MIME format.
--=_alternative 0053ED7665257F9D_=
Content-Type: text/plain; charset="US-ASCII"

Hi Esko,
Thanks for your mail.
First of all let me just bring this to your (as well as the mailing 
list's) notice that the latest version of the draft is:            
https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-16.txt 


This version "officially" closes the technical reviews and is with the RFC 
editor through the IS track. 

Now coming to your use case (and indeed it is an interesting one) one 
thing that we should consider is that the No-Response option was 
deliberately designed not to mandate anything for the server side mainly 
to ensure that it does not disrupt the many usefulness of the usual 
request/response symantics. The draft all along deals with the requesting 
client's behaviour and its expression of interest to the server. Since 
this option is elective we leave it upto the server implementation to 
honour the client's interest. 

Now, as per usual request/response symantics the responses are always 
enabled. The behaviour in groupcomm server in terms of suppressing the 
responses on its own is something special and, generally speaking, the 
clients are not aware of such special behaviour. 

So, it would be justified to handle the situation at the server's end. 
Here is the idea:
While No-Response is to expresses client's dis-interest in some or all of 
the responses depending on the option value, it is also true that the 
option automatically expresses interest in all other responses (marked by 
0's in the respective positions). The client is going to wait for these 
responses upto a given timeout. Now, if the server behaviour is modified 
like this : "I have closed my door for all out going response. **BUT**, if 
I see a fellow requesting with No-Response and keeping windows open to 
some responses then I assume that this guy really needs those kind of 
responses. In that case let me be linient and let me open the door for 
such responses. This fellow must be available to listen to them as per the 
prescribed behaviour in the No-Response specification." 

Mandating such server behaviour from the client side will be a bit 
out-of-sync with the spirit of the specification. 

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________




From:   "Dijk, Esko" 
To:     Abhijan Bhattacharyya 
Cc:     Nevil Brownlee , "core@ietf.org WG" 

Date:   04/22/2016 05:43 PM
Subject:        Using draft-tcs-coap-no-response-option to *enable* 
responses



Hello Abhijan,

in our project we see a clear use case of using the No-Response Option to 
*enable* certain responses that are by default suppressed.  CoAP allows 
suppression of multicast responses by default, which is what we use for a 
lighting multicast use case. However for diagnostic usage we'd like to 
enable these responses again using the No-Response option which is 
perfectly suited for that. However, the draft text currently only talks 
about suppressing responses (not enabling).

Hence my request: could we modify/add some text to show that also the 
option can be used to enable responses in case where they are normally (by 
default -- server decision) suppressed?
Just to clarify such usage; which is quite useful in my view.

regards
Esko

________________________________
The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby 
notified that any use, forwarding, dissemination, or reproduction of this 
message is strictly prohibited and may be unlawful. If you are not the 
intended recipient, please contact the sender by return e-mail and destroy 
all copies of the original message.

=====-----=====-----=====
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 0053ED7665257F9D_=
Content-Type: text/html; charset="US-ASCII"

Hi Esko,

Thanks for your mail.

First of all let me just bring this
to your (as well as the mailing list's) notice that the latest version
of the draft is:      
     https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-16.txt




This version "officially"
closes the technical reviews and is with the RFC editor through the IS
track. 



Now coming to your use case (and indeed
it is an interesting one) one thing that we should consider is that the
No-Response option was deliberately designed not to mandate anything for
the server side mainly to ensure that it does not disrupt the many usefulness
of the usual request/response symantics. The draft all along deals with
the requesting client's behaviour and its expression of interest to the
server. Since this option is elective we leave it upto the server implementation
to honour the client's interest. 



Now, as per usual request/response symantics
the responses are always enabled. The behaviour in groupcomm server in
terms of suppressing the responses on its own is something special and,
generally speaking, the clients are not aware of such special behaviour.
 



So, it would be justified to handle
the situation at the server's end. Here is the idea:

While No-Response is to expresses client's
dis-interest in some or all of the responses depending on the option value,
it is also true that the option automatically expresses interest in all
other responses (marked by 0's in the respective positions). The client
is going to wait for these responses upto a given timeout. Now, if the
server behaviour is modified like this : "I have closed my door for
all out going response. **BUT**, if I see a fellow requesting with No-Response
and keeping windows open to some responses then I assume that this guy
really needs those kind of responses. In that case let me be linient and
let me open the door for such responses. This fellow must be available
to listen to them as per the prescribed behaviour in the No-Response specification."
  



Mandating such server behaviour from
the client side will be a bit out-of-sync with the spirit of the specification.




Regards

Abhijan Bhattacharyya

Associate Consultant

Scientist, Innovation Lab, Kolkata, India

Tata Consultancy Services

Mailto: abhijan.bhattacharyya@tcs.com

Website: http://www.tcs.com

____________________________________________

Experience certainty.        IT Services

                
       Business Solutions

                
       Consulting

____________________________________________









From:      
 "Dijk, Esko"
<esko.dijk@philips.com>

To:      
 Abhijan Bhattacharyya
<abhijan.bhattacharyya@tcs.com>

Cc:      
 Nevil Brownlee <rfc-ise@rfc-editor.org>,
"core@ietf.org WG" <core@ietf.org>

Date:      
 04/22/2016 05:43 PM

Subject:    
   Using draft-tcs-coap-no-response-option
to *enable* responses









Hello Abhijan,



in our project we see a clear use case of using the No-Response Option
to *enable* certain responses that are by default suppressed.  CoAP
allows suppression of multicast responses by default, which is what we
use for a lighting multicast use case. However for diagnostic usage we'd
like to enable these responses again using the No-Response option which
is perfectly suited for that. However, the draft text currently only talks
about suppressing responses (not enabling).



Hence my request: could we modify/add some text to show that also the option
can be used to enable responses in case where they are normally (by default
-- server decision) suppressed?

Just to clarify such usage; which is quite useful in my view.



regards

Esko



________________________________

The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message
is strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original message.



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

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 0053ED7665257F9D_=--


From nobody Sat Apr 23 04:21:31 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2018612D79B for ; Sat, 23 Apr 2016 04:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level: 
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLwvVH1WMa4F for ; Sat, 23 Apr 2016 04:21:29 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2186112D6DC for ; Sat, 23 Apr 2016 04:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1461410488; d=isode.com; s=selector; i=@isode.com; bh=AhcWmd86+c8nJw3ZtPm2QWJHtiIEXGWc8jL7FM6GL2Q=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WKS0nwGp4RBZJXcMR5PzMM3MeBLLUaZvGFDg5L/u+6Z2lErPg3GODpYJjIFfWmfgV+ZGAx 1HICB0CYViBl8Tl7Ygslc8eIvyxTjtbKzIcWbXrF1QNBYQiXsINjINh54WEiXAzyFccWoa WrZ0oz1IhVxBjUkpOh98lOrf4oxaaak=;
Received: from [192.168.0.2] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Sat, 23 Apr 2016 12:21:28 +0100
To: "core@ietf.org WG" 
References: <57054B35.50700@tzi.org>
From: Alexey Melnikov 
Message-ID: <571B5AB0.5040309@isode.com>
Date: Sat, 23 Apr 2016 12:21:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <57054B35.50700@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_Confirmation_call=3A_CoAP_over_TCP/?= =?utf-8?q?TLS_=23396=3A_Revert_L1_selection=2C_select_L3?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Apr 2016 11:21:30 -0000

On 06/04/2016 18:45, Carsten Bormann wrote:
> As discussed in a previous message, the in-room consensus in Buenos
> Aires was to revert the decision we made in Yokohama to go for
> alternative L1, and to instead select alternative L3.
> 
> This is a one-week call for confirmation of that decision.
> Specifically, if you have an objection to this decision, please speak up
> on the mailing list by 2016-04-13.

As Carsten is listed one of the editors and he currently has no
co-chair, he asked me to officially close this confirmation call.

I've heard no objections to this change.

Best Regards,
Alexey,
Responsible ART AD for the CORE WG


From nobody Sat Apr 23 05:07:23 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9C612D90D for ; Sat, 23 Apr 2016 05:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level: 
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQTmWO0mubPX for ; Sat, 23 Apr 2016 05:07:20 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 846EC12D179 for ; Sat, 23 Apr 2016 05:07:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1461413239; d=isode.com; s=selector; i=@isode.com; bh=ZqNz9LHWMOAYyqkQbtxrvVk8+fIc0o6DjkeA34n6cPY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Bs30pIdjtI5ubtjD8Aa1K4e60AoNVGfwHTYBo5HL5xL6aFJJlfH5bz2VpCIk3Hovs77AmB 6JDX7Hl0Nu/efxnj2vYg0YeMT49M2bumbb8akaEJBpSyCUtJDWC5V/oMerNz7U143syrQ2 CsCvZ7e7XPIZw/C7BzrGmS7n39ZjKKg=;
Received: from [192.168.0.2] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Sat, 23 Apr 2016 13:07:19 +0100
To: Carsten Bormann 
References: <5707D6F8.40000@isode.com> <57186FC3.9010405@tzi.org>
From: Alexey Melnikov 
Message-ID: <571B6571.5010602@isode.com>
Date: Sat, 23 Apr 2016 13:07:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <57186FC3.9010405@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] Incoming AD review of draft-ietf-core-block-19
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Apr 2016 12:07:22 -0000

Hi Carsten,
Thank you for your responses. Further discussions below:

On 21/04/2016 07:14, Carsten Bormann wrote:
> Alexey Melnikov wrote:
>> Hi,
>> I am mostly happy with this document, but I have a few comments/questions=
:
>>
>> On page 11:
>>
>>    Clients that want to retrieve
>>    all blocks of a resource SHOULD strive to do so without undue delay.
>>
>> This is not an interoperability issue and it would be impossible to
>> verify compliance with it, unless you have a number that specifies what
>> is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here.
>> Just use lowercased "should" instead.
>=20
> Indeed, you cannot measure compliance with this SHOULD.  I still think
> that it is important for interoperability to point out that clients will
> have more successful exchanges if they heed this.  (From an
> interoperability point of view, this is a statement that relieves
> servers of a potential onus to somehow cater for clients that don't.)
>=20
>> Similarly, in 2.5:
>>
>>    Clients SHOULD strive to send all blocks of a
>>    request without undue delay.
>>
>> (Similar text in 2.6)
>=20
> (Ditto.)

I think I prefer to have some recommendations on what is "undue delay",
if you can add some text.

>> In 2.9.2:
>>
>> Should probably also mention that this response code is also used for
>>  mismatching content-format options
>=20
> That is one way to see this; section 2.3 takes the view that mismatching
> content-formats aren't reassembled into one body in the first place so
> an incomplete body is the result of not having all parts.
> (I added back reference in the editor's draft.)

What is the state of the resource in such condition?

>> In 2.10:
>>
>>    A response with a Block1 Option in control usage
>>    with the M bit set invalidates cached responses for the target URI.
>>
>> Can you explain the reason for this?
>=20
>=20
> If the M bit had not been set the response would have been a final
> response and would be used to update the cache entries for this URI.
> Now, with the M bit set, we know that there will be a final response
> later, but we don't know what that will be.  Continuing to serve a
> previous response from the cache doesn't sound right.  But then, it
> could be argued that the server just promised to perform the request
> atomically later, so nothing has happened yet.  Good question.
>=20
>>
>> In 3.2:
>>
>>    A stateless server that simply builds/updates the resource in place
>>    (statelessly) may indicate this by not setting the more bit in the
>>    response (Figure 8); in this case, the response codes are valid
>>    separately for each block being updated.
>>
>> What is the behaviour of both the client and the server if PUT on a
>> particular block fails? Is this clear enough in the document?
>=20
> In the stateless case, the resource is now probably broken (unless the
> resource is somehow intrinsically robust to this case).  The client
> should not be using the resource (e.g., try to initiate a firmware
> update from an image it just has been building).  The server is
> stateless with respect to individual requests, so it is patiently
> sitting there for the broken resource to be mended.

How can a resource be "mended" if a PUT failed? I think it would be
reasonable for a server implementation to discard the whole accumulated
payload, so there would be no way to mend it other than by uploading the
whole thing from the beginning. If my interpretation is invalid, I
welcome some clarifications on this.

So I think this needs more clarifying text, either describing what
client might be able to do to fix the resource or explaining that the
client need to restart upload.

>> Other questions I have after reviewing the document. If I missed where
>> they are answered, please point me out to existing text in the document
>> or another RFC:
>>
>> Is there a special error for block size mismatch between multiple request=
s?
>=20
> A block size mismatch is not an error (maybe I don't understand the
> question).

There are MUSTs in the document saying that if one end signalled a
certain block size, the other party needs to use the same or smaller
size. What happens if the other party doesn't obey this rule. Is there a
special error code that can be used to signal that a request is rejected
because the specified block size is too big?

>> As block2 is a critical option, how can a server know if a particular
>> client supports this option?
>=20
> The assumption here is that CoAP clients generally do, unless they are
> very specialized and never have to deal with non-trivial amounts of
> information (such as a /.well-known/core).

Is this generally true for all COAP extensions or just some?

Extensibility for most protocols is done by capability
discovery/negotiation and graceful service degradation in absence of a
particular extension. This seems to violate this principle.


From nobody Sat Apr 23 07:23:40 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6E12D0FB for ; Sat, 23 Apr 2016 07:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 e_JYTtIGKGAy for ; Sat, 23 Apr 2016 07:23:37 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B82E12D6F1 for ; Sat, 23 Apr 2016 07:23:37 -0700 (PDT)
Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id EDC8841C086; Sat, 23 Apr 2016 16:23:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id yTAzQXJ2vKxB; Sat, 23 Apr 2016 16:23:34 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 3485A41C093; Sat, 23 Apr 2016 16:23:33 +0200 (CEST)
Message-ID: <571B8563.2090508@tzi.org>
Date: Sat, 23 Apr 2016 16:23:31 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Alexey Melnikov 
References: <5707D6F8.40000@isode.com> <57186FC3.9010405@tzi.org> <571B6571.5010602@isode.com>
In-Reply-To: <571B6571.5010602@isode.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] Incoming AD review of draft-ietf-core-block-19
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Apr 2016 14:23:39 -0000

Alexey Melnikov wrote:
> Hi Carsten,
> Thank you for your responses. Further discussions below:
> 
> On 21/04/2016 07:14, Carsten Bormann wrote:
>> Alexey Melnikov wrote:
>>> Hi,
>>> I am mostly happy with this document, but I have a few comments/questions:
>>>
>>> On page 11:
>>>
>>>    Clients that want to retrieve
>>>    all blocks of a resource SHOULD strive to do so without undue delay.
>>>
>>> This is not an interoperability issue and it would be impossible to
>>> verify compliance with it, unless you have a number that specifies what
>>> is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here.
>>> Just use lowercased "should" instead.
>> Indeed, you cannot measure compliance with this SHOULD.  I still think
>> that it is important for interoperability to point out that clients will
>> have more successful exchanges if they heed this.  (From an
>> interoperability point of view, this is a statement that relieves
>> servers of a potential onus to somehow cater for clients that don't.)
>>
>>> Similarly, in 2.5:
>>>
>>>    Clients SHOULD strive to send all blocks of a
>>>    request without undue delay.
>>>
>>> (Similar text in 2.6)
>> (Ditto.)
> 
> I think I prefer to have some recommendations on what is "undue delay",
> if you can add some text.

Delay for which there isn't a good reason?

Another way to say this would be: "Servers will not go out of their way
to accommodate clients that take forever to finish a block-wise
transfer.  If the resource changes while this proceeds, the ETag for a
further block obtained may be different.  To avoid this happening all
the time for a fast-changing resource, a server MAY try to keep a cache
around for a specific client for a short amount of time, but the
lifetime for such a cache may be short, on the order of a few expected
round-trip times, counting from the previous block transferred."

Should we go to this level of detail here?

>>> In 2.9.2:
>>>
>>> Should probably also mention that this response code is also used for
>>>  mismatching content-format options
>> That is one way to see this; section 2.3 takes the view that mismatching
>> content-formats aren't reassembled into one body in the first place so
>> an incomplete body is the result of not having all parts.
>> (I added back reference in the editor's draft.)
> 
> What is the state of the resource in such condition?

We didn't make a guarantee here; after all, the client just violated a
MUST.  A good server will just reject a block-wise transfer with NUM≠0
and a different content-format than the current state of the resource:
Either it is stateless, and it matches up the content-format of the
block against that of the existing resource, or it is atomic, in which
case it matches up the block against the partially reassembled piece of
representation that is going to replace the state of the resource.

>>> In 2.10:
>>>
>>>    A response with a Block1 Option in control usage
>>>    with the M bit set invalidates cached responses for the target URI.
>>>
>>> Can you explain the reason for this?
>>
>> If the M bit had not been set the response would have been a final
>> response and would be used to update the cache entries for this URI.
>> Now, with the M bit set, we know that there will be a final response
>> later, but we don't know what that will be.  Continuing to serve a
>> previous response from the cache doesn't sound right.  But then, it
>> could be argued that the server just promised to perform the request
>> atomically later, so nothing has happened yet.  Good question.
>>
>>> In 3.2:
>>>
>>>    A stateless server that simply builds/updates the resource in place
>>>    (statelessly) may indicate this by not setting the more bit in the
>>>    response (Figure 8); in this case, the response codes are valid
>>>    separately for each block being updated.
>>>
>>> What is the behaviour of both the client and the server if PUT on a
>>> particular block fails? Is this clear enough in the document?
>> In the stateless case, the resource is now probably broken (unless the
>> resource is somehow intrinsically robust to this case).  The client
>> should not be using the resource (e.g., try to initiate a firmware
>> update from an image it just has been building).  The server is
>> stateless with respect to individual requests, so it is patiently
>> sitting there for the broken resource to be mended.
> 
> How can a resource be "mended" if a PUT failed? I think it would be
> reasonable for a server implementation to discard the whole accumulated
> payload, so there would be no way to mend it other than by uploading the
> whole thing from the beginning. If my interpretation is invalid, I
> welcome some clarifications on this.

If the server is stateless (in-place replace), the failed PUT may have
had no effect (which should be the case for 4.xx response), so the
client can try doing something else to that block.  If there was a 5.xx
response, that is harder to say.  But the real problem is that the
previous blocks may already have had an effect on the resource, so it
may be inconsistent/incomplete.

> So I think this needs more clarifying text, either describing what
> client might be able to do to fix the resource or explaining that the
> client need to restart upload.

Right, I'll try to separate out the cases and add some text (but not
here in the examples).

>>> Other questions I have after reviewing the document. If I missed where
>>> they are answered, please point me out to existing text in the document
>>> or another RFC:
>>>
>>> Is there a special error for block size mismatch between multiple requests?
>> A block size mismatch is not an error (maybe I don't understand the
>> question).
> 
> There are MUSTs in the document saying that if one end signalled a
> certain block size, the other party needs to use the same or smaller
> size. What happens if the other party doesn't obey this rule. Is there a
> special error code that can be used to signal that a request is rejected
> because the specified block size is too big?

Well, one problem that a client gets if it *increases* the block size is
that it probably can't hit the place where it was (which, at least
initially, is an odd number at the smaller size, so it's not integer at
the larger size).  Say, a client asks for 128 for block 0, but the
server only sends 64; then asking for 128 for block 1 is going to leave
a hole (byte 64 to 127).  Now, if the client instead asks for 64 for
block 1 and then goes back 128 for block 1 (!), the parts do fit
together, but I'd expect the server to be stubborn and again send 64 for
block 2 (!).  This is the Block2 case.  For Block1, we have 4.13.

>>> As block2 is a critical option, how can a server know if a particular
>>> client supports this option?
>> The assumption here is that CoAP clients generally do, unless they are
>> very specialized and never have to deal with non-trivial amounts of
>> information (such as a /.well-known/core).
> 
> Is this generally true for all COAP extensions or just some?

Just this one.  Block-wise transfers were part of the design for the
CoAP protocol from the start, and implementers have been aware that they
had to do block-wise in order to support non-trivial payload sizes (but
they don't have to do them if they don't need to).

> Extensibility for most protocols is done by capability
> discovery/negotiation and graceful service degradation in absence of a
> particular extension. This seems to violate this principle.

Right.  So, for instance Observe was designed so that it can be
gracefully ignored by a server that doesn't implement it.  We still put
a mechanism in RFC 6690 so a server can signal that it offers Observe
for a resource.  I would expect similar out of band information to be
provided for future extensions, so a client doesn't have to waste a
round-trip trying out the extension.  Block is slightly weird in that a
server may need to offer the (critical) extension unsolicited for an
unextended request; we'd try to avoid that for any new extension, but
here we do have the luxury.

Grüße, Carsten


From nobody Sun Apr 24 12:28:44 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182012B01E for ; Sun, 24 Apr 2016 12:28:43 -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] 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 8fwlLxvF8_2l for ; Sun, 24 Apr 2016 12:28:41 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8A512B00D for ; Sun, 24 Apr 2016 12:28:41 -0700 (PDT)
Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 9AF77C5A50; Sun, 24 Apr 2016 21:28:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id vAiErADkNtzo; Sun, 24 Apr 2016 21:28:37 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 46B96C5A5D; Sun, 24 Apr 2016 21:28:37 +0200 (CEST)
Message-ID: <571D1E63.9090003@tzi.org>
Date: Sun, 24 Apr 2016 21:28:35 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: j.schoenwaelder@jacobs-university.de
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local>
In-Reply-To: <20160421174806.GA8710@elstar.local>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Apr 2016 19:28:43 -0000

Hi Juergen,

trying to read your message -- are you just commenting on the side
conversation here or is this also a comment on the adoption call?

Grüße, Carsten


Juergen Schoenwaelder wrote:
> On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
>> First, LWM2M have its own modeling language encoded in xml.
>> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang.
>> A simple xml transform can probably do the conversion between the two without any lost.
>> LWM2M just have a simpler (subset) modeling language.
>>
> 
> These are pretty bold statements. Claiming something is simple and
> knowing something is simple are sometimes different things. Have you
> worked throught the details? Is there a decent public definition of
> the 'simpler (subset) modeling language'? And with public I mean
> public, not hidden behind all sorts of registration walls.
> 
> /js
> 


From nobody Mon Apr 25 01:29:45 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2CC12D4FB for ; Mon, 25 Apr 2016 01:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 54kX0r0ZrBiM for ; Mon, 25 Apr 2016 01:29:42 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E8712B064 for ; Mon, 25 Apr 2016 01:29:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 68698E71; Mon, 25 Apr 2016 10:29:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4oyv80btnq6W; Mon, 25 Apr 2016 10:29:38 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Apr 2016 10:29:39 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75EED2004E; Mon, 25 Apr 2016 10:29:39 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XZJ5f2_kWHE3; Mon, 25 Apr 2016 10:29:38 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E42B2004A; Mon, 25 Apr 2016 10:29:38 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 667793AB4768; Mon, 25 Apr 2016 10:29:38 +0200 (CEST)
Date: Mon, 25 Apr 2016 10:29:38 +0200
From: Juergen Schoenwaelder 
To: Carsten Bormann 
Message-ID: <20160425082938.GB16839@elstar.local>
Mail-Followup-To: Carsten Bormann , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <571D1E63.9090003@tzi.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Apr 2016 08:29:44 -0000

I guess it is side conversation for this thread. ;-)

I have been pushing for factoring the YANG to CBOR mapping out of the
COMI documents and hence I am happy that this is now happening and
hence I am supportive.

/js

On Sun, Apr 24, 2016 at 09:28:35PM +0200, Carsten Bormann wrote:
> Hi Juergen,
> 
> trying to read your message -- are you just commenting on the side
> conversation here or is this also a comment on the adoption call?
> 
> Grüße, Carsten
> 
> 
> Juergen Schoenwaelder wrote:
> > On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
> >> First, LWM2M have its own modeling language encoded in xml.
> >> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang.
> >> A simple xml transform can probably do the conversion between the two without any lost.
> >> LWM2M just have a simpler (subset) modeling language.
> >>
> > 
> > These are pretty bold statements. Claiming something is simple and
> > knowing something is simple are sometimes different things. Have you
> > worked throught the details? Is there a decent public definition of
> > the 'simpler (subset) modeling language'? And with public I mean
> > public, not hidden behind all sorts of registration walls.
> > 
> > /js
> > 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Apr 25 03:20:04 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381DE12D12A for ; Mon, 25 Apr 2016 03:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 8_OkkzWpQymu for ; Mon, 25 Apr 2016 03:20:01 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBE612D093 for ; Mon, 25 Apr 2016 03:20:00 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MHX0m-1arKEZ1Gv6-003KQ1; Mon, 25 Apr 2016 12:19:47 +0200
To: Carsten Bormann , j.schoenwaelder@jacobs-university.de
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <571DEF4A.50506@gmx.net>
Date: Mon, 25 Apr 2016 12:19:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <571D1E63.9090003@tzi.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pf06uxjxWswAHbPsq0qSXg7BbJjcuSUN3"
X-Provags-ID: V03:K0:kFpEv21NBVGz0OdvPqIFx28stY/WGftprKvtuChQUm4P5MVMhcN dZje02kGLpsqFb6lfk3R9JBRSXRdhujwT3yW72pDwm7dfv2TJlAWbUkfI5S2lFQovI91Bsr EHk+csKV5Q/oOo/g5PIy2frmJtsoHGbAolgR7maj/koaEiQDLiviCBynGWSJ9BUUjTIbKKZ 2nfczfS3KhMwqMF6ar6Qg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2Ul0nCKle/w=:oSObIPP4D0HSh+eHw1vwTK BjFLz0CiPgTxabogpx3xh0g0ItTsLGfqrq7d+rHEGBPSlKxNgI50RCeh7SkwdNoCOs55Gp50B N7QO3FlivWuapIbuygFUkQFSWkR8mZmQrPYq4S5Womm2ixUCXzWEBHe8CUCD1R2n4FZbOAgCQ LRZTlr/8fdY296RRTOp3uzfg11wh0hi+7c774DXrarKYPGLZGBfL/CqZ8Ap8Se0eeiK4KLAOA Rxi7g4JVG3Ka2BuMnMDe9jju44ho+8xFlNRUuIsZ4jWBfRdJ0PbiEV4MVQjaz0+v4+Hlaet1N ytnvFQD9m8eKe5NO61y80H+7v9qni80RxM+wwlBbiMGXfvUa0OlWjjNaHjc7x6t3vsNMmzOpf X6gJpfdGDMlhun+QgcdpLix6URUogD3rz9pmFqlhguj2HfM0eod7pE/hyo9X+BqNCy6HSNIaW 0gDWiQXxnuxqf4khbBiz/fFsFxXI6WtcWkOqObeY2ISIJGZhmOhRjpLIXmwjiNBJ1sKDIniKo KcNUWWAny4TaCKDCoBjeL3E3xZNL3WNM+iSpfKMvzdh5kEkXeWRDLJf7x2EfuaOFj07xwPY/q JhFd0zzVh0RQeiUJAXDyQB4Waj/cWuI7WPA5MEY6AXpDczeXCPUmJaP6XhZfjJdM9hYU9znd0 XOQofszDZse/rQCmR3CBIM2+f0VFBiYVJ5YiW8LI+o5Vs2AwUUHFyMkgpWUVzbaa29SidXeUB u1/s2DZ5rF9Iz4mtPZz9mcewaE0azwfnkBFcUbIFqP9akM1zn+yKcQf6XT4=
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Apr 2016 10:20:03 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pf06uxjxWswAHbPsq0qSXg7BbJjcuSUN3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Juergen, Hi Carsten,

The data modelling language used by OMA LWM2M is an XML schema and the
OMA only uses it for two purposes:

 * Adding new objects and resources to the registry allows automatic
validation (of the XML instance documents against the XML schema).

 * The XML schema really only models the data and does not attempt to
describe the interaction.

There has been no attempt to generate code from the XML instance
documents (as far as I know).

I have tried to take a subset of the device object and to describe it in
Yang. To my knowledge nobody has tried to describe all currently
registered objects with Yang.

In any case, here is what I have tried:

----

module LWM2M_Device {
	// header information
	yang-version "1";
	namespace "foobar1";		=09
	prefix "LWM2M_Device";
=09
	// linkage statements
	import extensions {
		prefix extensions;
		ietf-yang-types@2013-07-15.yang;
	}
=09
	// meta information
	organization "OMA";
	contact "foobar2";
	description
		"This object provides a range of device related information which can
be queried by the LWM2M Server, and a device reboot and factory reset
function.";
	reference
"http://technical.openmobilealliance.org/tech/profiles/LWM2M_Device-v1_0.=
xml";
=09
	// revision history
	revision 2016-04-20 {
		description "Initial revision.";
		reference "";
	}
=09
	// module definitions
	extensions:LWM2M_Object_ID "3";
=09
	// typedef statements
=09
	// data statements
=09
	leaf Manufacturer {
		extensions:LWM2M_Resource_ID "0";
        type string;
		config true;
		description "Human readable manufacturer name";
	}
=09
	leaf ModelNumber {
		extensions:LWM2M_Resource_ID "1";
		type String;
		config true;
		description "A model identifier
                (manufacturer specified string).";
	}
=09
	leaf SerialNumber {
		extensions:LWM2M_Resource_ID "2";
		type String;
		config true;
		description "Serial Number.";
	}
=09
	leaf AvailablePowerSources {
		extensions:LWM2M_Resource_ID "6";
		type int32 {
                  range "0..7";
                };	=09
		config true;
		description "
 0 =E2=80=93 DC power
 1 =E2=80=93 Internal Battery
 2 =E2=80=93 External Battery
 4 =E2=80=93 Power over Ethernet
 5 =E2=80=93 USB
 6 =E2=80=93 AC (Mains) power
 7 =E2=80=93 Solar";
	}
=09
	leaf BatteryLevel {
		extensions:LWM2M_Resource_ID "9";
		type int32 {
            range "0..100";
        };
		units percent;
		config false;
		description "Contains the current battery level as a percentage (with
a range from 0 to 100). This value is only valid when the value of
Available Power Sources Resource is 1.";
	}
=09
	leaf MemoryFree {
		extensions:LWM2M_Resource_ID "10";
		type int32;
		units KB;
		config false;
		description "Estimated current available amount of storage space which
can store data and software in the LWM2M Device (expressed in kilobytes).=
";
	}
=09
	leaf CurrentTime {
		extensions:LWM2M_Resource_ID "13";
		type timestamp;
		units KB;
		config false;
		description "Current UNIX time of the LWM2M Client. The LWM2M Client
should be responsible to increase this time value as every second
elapses. The LWM2M Server is able to write this Resource to make the
LWM2M Client synchronized with the LWM2M Server.";
	}
=09
}

----

The problem I have is to find out whether Yang is able to also describe
the interaction model of OMA LWM2M. I believe the current understanding
is that this is not possible without some extensions. Please correct me.

Ciao
Hannes


On 04/24/2016 09:28 PM, Carsten Bormann wrote:
> Hi Juergen,
>=20
> trying to read your message -- are you just commenting on the side
> conversation here or is this also a comment on the adoption call?
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
> Juergen Schoenwaelder wrote:
>> On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
>>> First, LWM2M have its own modeling language encoded in xml.
>>> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not funda=
mentally different than something than can be named security.yang.
>>> A simple xml transform can probably do the conversion between the two=
 without any lost.
>>> LWM2M just have a simpler (subset) modeling language.
>>>
>>
>> These are pretty bold statements. Claiming something is simple and
>> knowing something is simple are sometimes different things. Have you
>> worked throught the details? Is there a decent public definition of
>> the 'simpler (subset) modeling language'? And with public I mean
>> public, not hidden behind all sorts of registration walls.
>>
>> /js
>>
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20


--pf06uxjxWswAHbPsq0qSXg7BbJjcuSUN3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXHe9KAAoJEGhJURNOOiAt9FcH/0+HDF1ey/dyAs6Yi1ACo4cG
QmfJh6UTkp7vya/q7s4z1/ZZtjCGUam9AAzZ8dDFuCblmO0TvRTL1x6bbDOHSznv
n3g2f4IqDKIWK0/BTy88fn5ZbDe9kt3Vo2jxx6ahCU0+pIa18nTpz512QFfiLY56
FF47N4Rsoza1DNJn7lcJMAkhXCgupuwCPd+L+RJGWOgqiJOXLsZyvY8hYZD3WIog
gR8lJolSrkw/uTtgl7j7RQmyCHcanxgxIGMmC6CtxHPLUePKz60Eee4IAF4LOPyn
me3GmUQBYBBKKB19+D3CqjDqf38v6tev5wZwJREfSawZNDUYLRGdOzVbjtSzacU=
=0ANx
-----END PGP SIGNATURE-----

--pf06uxjxWswAHbPsq0qSXg7BbJjcuSUN3--


From nobody Mon Apr 25 03:33:58 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4512D508 for ; Mon, 25 Apr 2016 03:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 FVGIFx-hJDKJ for ; Mon, 25 Apr 2016 03:33:54 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DB212D15E for ; Mon, 25 Apr 2016 03:33:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 65A88879; Mon, 25 Apr 2016 12:33:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sVDSzKn5BINi; Mon, 25 Apr 2016 12:33:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 25 Apr 2016 12:33:51 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E16372007B; Mon, 25 Apr 2016 12:33:50 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Q1IEya8nZY0R; Mon, 25 Apr 2016 12:33:49 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 842182005E; Mon, 25 Apr 2016 12:33:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E3D863AB4BD7; Mon, 25 Apr 2016 12:33:38 +0200 (CEST)
Date: Mon, 25 Apr 2016 12:33:38 +0200
From: Juergen Schoenwaelder 
To: Hannes Tschofenig 
Message-ID: <20160425103338.GA17158@elstar.local>
Mail-Followup-To: Hannes Tschofenig , Carsten Bormann , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org> <571DEF4A.50506@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <571DEF4A.50506@gmx.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Apr 2016 10:33:57 -0000

Hannes,

whether this YANG fragment makes sense or not I simply do not know
without knowing LWM2M and since there are no open specs there is
little help you can expect. I have no clue about the interaction model
of OMA LWM2M nor do I know what LWM2M_Device is etc.

The claim was made that there is a 'simple' conversion (and I read
that as 'simple algorithm' to do conversion) and all I am asking is
whether someone actually went through the details of this. All I saw
so far are sketches of examples, thats good for a start but still
likely a longer way from a 'simple algorithm' (if that was the
intention).

But we should really be using a different thread - or simply wait
until someone managed to work out the details and got permission from
OMA to write it down without violating their legal constraints they
put on their registration wall.

/js

On Mon, Apr 25, 2016 at 12:19:54PM +0200, Hannes Tschofenig wrote:
> Hi Juergen, Hi Carsten,
> 
> The data modelling language used by OMA LWM2M is an XML schema and the
> OMA only uses it for two purposes:
> 
>  * Adding new objects and resources to the registry allows automatic
> validation (of the XML instance documents against the XML schema).
> 
>  * The XML schema really only models the data and does not attempt to
> describe the interaction.
> 
> There has been no attempt to generate code from the XML instance
> documents (as far as I know).
> 
> I have tried to take a subset of the device object and to describe it in
> Yang. To my knowledge nobody has tried to describe all currently
> registered objects with Yang.
> 
> In any case, here is what I have tried:
> 
> ----
> 
> module LWM2M_Device {
> 	// header information
> 	yang-version "1";
> 	namespace "foobar1";			
> 	prefix "LWM2M_Device";
> 	
> 	// linkage statements
> 	import extensions {
> 		prefix extensions;
> 		ietf-yang-types@2013-07-15.yang;
> 	}
> 	
> 	// meta information
> 	organization "OMA";
> 	contact "foobar2";
> 	description
> 		"This object provides a range of device related information which can
> be queried by the LWM2M Server, and a device reboot and factory reset
> function.";
> 	reference
> "http://technical.openmobilealliance.org/tech/profiles/LWM2M_Device-v1_0.xml";
> 	
> 	// revision history
> 	revision 2016-04-20 {
> 		description "Initial revision.";
> 		reference "";
> 	}
> 	
> 	// module definitions
> 	extensions:LWM2M_Object_ID "3";
> 	
> 	// typedef statements
> 	
> 	// data statements
> 	
> 	leaf Manufacturer {
> 		extensions:LWM2M_Resource_ID "0";
>         type string;
> 		config true;
> 		description "Human readable manufacturer name";
> 	}
> 	
> 	leaf ModelNumber {
> 		extensions:LWM2M_Resource_ID "1";
> 		type String;
> 		config true;
> 		description "A model identifier
>                 (manufacturer specified string).";
> 	}
> 	
> 	leaf SerialNumber {
> 		extensions:LWM2M_Resource_ID "2";
> 		type String;
> 		config true;
> 		description "Serial Number.";
> 	}
> 	
> 	leaf AvailablePowerSources {
> 		extensions:LWM2M_Resource_ID "6";
> 		type int32 {
>                   range "0..7";
>                 };		
> 		config true;
> 		description "
>  0 – DC power
>  1 – Internal Battery
>  2 – External Battery
>  4 – Power over Ethernet
>  5 – USB
>  6 – AC (Mains) power
>  7 – Solar";
> 	}
> 	
> 	leaf BatteryLevel {
> 		extensions:LWM2M_Resource_ID "9";
> 		type int32 {
>             range "0..100";
>         };
> 		units percent;
> 		config false;
> 		description "Contains the current battery level as a percentage (with
> a range from 0 to 100). This value is only valid when the value of
> Available Power Sources Resource is 1.";
> 	}
> 	
> 	leaf MemoryFree {
> 		extensions:LWM2M_Resource_ID "10";
> 		type int32;
> 		units KB;
> 		config false;
> 		description "Estimated current available amount of storage space which
> can store data and software in the LWM2M Device (expressed in kilobytes).";
> 	}
> 	
> 	leaf CurrentTime {
> 		extensions:LWM2M_Resource_ID "13";
> 		type timestamp;
> 		units KB;
> 		config false;
> 		description "Current UNIX time of the LWM2M Client. The LWM2M Client
> should be responsible to increase this time value as every second
> elapses. The LWM2M Server is able to write this Resource to make the
> LWM2M Client synchronized with the LWM2M Server.";
> 	}
> 	
> }
> 
> ----
> 
> The problem I have is to find out whether Yang is able to also describe
> the interaction model of OMA LWM2M. I believe the current understanding
> is that this is not possible without some extensions. Please correct me.
> 
> Ciao
> Hannes
> 
> 
> On 04/24/2016 09:28 PM, Carsten Bormann wrote:
> > Hi Juergen,
> > 
> > trying to read your message -- are you just commenting on the side
> > conversation here or is this also a comment on the adoption call?
> > 
> > Grüße, Carsten
> > 
> > 
> > Juergen Schoenwaelder wrote:
> >> On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
> >>> First, LWM2M have its own modeling language encoded in xml.
> >>> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fundamentally different than something than can be named security.yang.
> >>> A simple xml transform can probably do the conversion between the two without any lost.
> >>> LWM2M just have a simpler (subset) modeling language.
> >>>
> >>
> >> These are pretty bold statements. Claiming something is simple and
> >> knowing something is simple are sometimes different things. Have you
> >> worked throught the details? Is there a decent public definition of
> >> the 'simpler (subset) modeling language'? And with public I mean
> >> public, not hidden behind all sorts of registration walls.
> >>
> >> /js
> >>
> > 
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> > 
> 



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Apr 25 04:03:43 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15E412D119 for ; Mon, 25 Apr 2016 04:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 oOc3VmfXpFMp for ; Mon, 25 Apr 2016 04:03:40 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C0812D10C for ; Mon, 25 Apr 2016 04:03:39 -0700 (PDT)
Received: from [192.168.10.140] ([195.149.223.228]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lt2BW-1bsLeG1E78-012c42; Mon, 25 Apr 2016 13:03:26 +0200
To: Carsten Bormann , "core@ietf.org WG" , j.schoenwaelder@jacobs-university.de
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org> <571DEF4A.50506@gmx.net> <20160425103338.GA17158@elstar.local>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <571DF986.6000200@gmx.net>
Date: Mon, 25 Apr 2016 13:03:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160425103338.GA17158@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u6qICgIH4qh26M2ENdBv4XGamiE8Gr5cq"
X-Provags-ID: V03:K0:jhvK7qXjn+Rs8Snabf+0YazLS6kuC1wdRm1HGkAczBAVZZo1g9l Y2cZxz9uO5qvSGUyeuAiKdFaeqvwo33h7grOTFnOEC0UtzP4hJj9qEh+9BtLYfLtHx/HS3N LZS2+KoXbbQd06syIeh1dvCOBInlIJVVOoHTZSTwTkfSRVlS0+gVvZ20yqtkGNOzdp8pxY5 hwXxo9gtoRJeof1yaRKPw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:WyZSJ5urzzs=:G50igUVTfS7HLBcSKlv7oY 4otzMBPbT7zX012lV7CtO/+Cnv9OJlb4+BleIK0hdOffBYcBkTrU43e9Dgso1p189KHovfqim qTq9KBKileR0e/aa6UVhJHz/dbXlb5r12ix0gLl5flFCf4GMtTIkHOL1cgS3Oo/J+jBiney3b P/6T3z4wywh6nqnzyvRQymqKyjalJyBt5uwkHCw9I0NSJUo7pmYKxGtDjJqfJqZ6cK0iKIbba 0AtWf0jqnl2RDpZwjx1eTEKYsOkwFBCwRZd2tUQM+5M6LCN41iqsi+Lz6I/FWXwlOOPwbOo6+ ErsiXOg3PODmF+Mu+YHYnNeun1jFyEiQ7ImTrkourJQUaZVlZP5+h3tY0EHCbSugeMUxakyx4 Hh3pPrboT0n2ET4QUxNZmHeix9PYiN3HMcI5LJPgWa+velXC0BrY+On7z9b0YQ8ry684nKXTP 4q4oKdRWeVy4eefnISIkcg0lUw+lVIz8OIx8WmiLXJiwDmuXAKY9dEQN3TDCkZuz3oqr5pzsM MYxA7ursaeYPPxs/IsNAiA2xz4/lTbJmG1lvkSHZhvjqUhb4RSHoHZ/YAwdH+HO3mnzQoCpQ/ wbn9YeVV9F5GhCiYCVmatldlLSuITkhhm4tH7MwqR2biJQQccE03QitF9+LDezVuE3JxJ86zC M//eedIpFOVoEt1XGM0lQLUbrJb8oJNWdEtx8jhlcD/zUrGDILj555Q7URh7h8MMVq3/XjmRt yKff4jI275R4/XTf295SMWMpESdkbqBTocIGTLRmOMXZHt78Y0TdRkHgKYk=
Archived-At: 
Subject: [core] Using Yang to describe LWM2M ... was Re: ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Apr 2016 11:03:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--u6qICgIH4qh26M2ENdBv4XGamiE8Gr5cq
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

On 04/25/2016 12:33 PM, Juergen Schoenwaelder wrote:
> Hannes,
>=20
> whether this YANG fragment makes sense or not I simply do not know
> without knowing LWM2M and since there are no open specs there is
> little help you can expect. I have no clue about the interaction model
> of OMA LWM2M nor do I know what LWM2M_Device is etc.

The specs are publically available for download at no cost.

Here is the link:
http://technical.openmobilealliance.org/Technical/technical-information/r=
elease-program/current-releases/oma-lightweightm2m-v1-0

You want to look at the 'Technical Specification'.

The registry for the objects are also public and available in a nicely
written page (similar to what IANA provides for the IETF):
http://technical.openmobilealliance.org/Technical/technical-information/o=
mna/lightweight-m2m-lwm2m-object-registry

>=20
> The claim was made that there is a 'simple' conversion (and I read
> that as 'simple algorithm' to do conversion) and all I am asking is
> whether someone actually went through the details of this. All I saw
> so far are sketches of examples, thats good for a start but still
> likely a longer way from a 'simple algorithm' (if that was the
> intention).

Nobody has gone through the details. This is one of my complaints as
well. There is this argument that we can do things easily with Yang
since it is such a powerful language but then nobody spends the time to
look at the already available solutions.

>=20
> But we should really be using a different thread

Changed the name of the Thread.

> - or simply wait
> until someone managed to work out the details and got permission from
> OMA to write it down without violating their legal constraints they
> put on their registration wall.

There is no permission that needs to be obtained IMHO, if I understand
the OMA copyright policy correctly.

Ciao
Hannes

>=20
> /js
>=20
> On Mon, Apr 25, 2016 at 12:19:54PM +0200, Hannes Tschofenig wrote:
>> Hi Juergen, Hi Carsten,
>>
>> The data modelling language used by OMA LWM2M is an XML schema and the=

>> OMA only uses it for two purposes:
>>
>>  * Adding new objects and resources to the registry allows automatic
>> validation (of the XML instance documents against the XML schema).
>>
>>  * The XML schema really only models the data and does not attempt to
>> describe the interaction.
>>
>> There has been no attempt to generate code from the XML instance
>> documents (as far as I know).
>>
>> I have tried to take a subset of the device object and to describe it =
in
>> Yang. To my knowledge nobody has tried to describe all currently
>> registered objects with Yang.
>>
>> In any case, here is what I have tried:
>>
>> ----
>>
>> module LWM2M_Device {
>> 	// header information
>> 	yang-version "1";
>> 	namespace "foobar1";		=09
>> 	prefix "LWM2M_Device";
>> =09
>> 	// linkage statements
>> 	import extensions {
>> 		prefix extensions;
>> 		ietf-yang-types@2013-07-15.yang;
>> 	}
>> =09
>> 	// meta information
>> 	organization "OMA";
>> 	contact "foobar2";
>> 	description
>> 		"This object provides a range of device related information which ca=
n
>> be queried by the LWM2M Server, and a device reboot and factory reset
>> function.";
>> 	reference
>> "http://technical.openmobilealliance.org/tech/profiles/LWM2M_Device-v1=
_0.xml";
>> =09
>> 	// revision history
>> 	revision 2016-04-20 {
>> 		description "Initial revision.";
>> 		reference "";
>> 	}
>> =09
>> 	// module definitions
>> 	extensions:LWM2M_Object_ID "3";
>> =09
>> 	// typedef statements
>> =09
>> 	// data statements
>> =09
>> 	leaf Manufacturer {
>> 		extensions:LWM2M_Resource_ID "0";
>>         type string;
>> 		config true;
>> 		description "Human readable manufacturer name";
>> 	}
>> =09
>> 	leaf ModelNumber {
>> 		extensions:LWM2M_Resource_ID "1";
>> 		type String;
>> 		config true;
>> 		description "A model identifier
>>                 (manufacturer specified string).";
>> 	}
>> =09
>> 	leaf SerialNumber {
>> 		extensions:LWM2M_Resource_ID "2";
>> 		type String;
>> 		config true;
>> 		description "Serial Number.";
>> 	}
>> =09
>> 	leaf AvailablePowerSources {
>> 		extensions:LWM2M_Resource_ID "6";
>> 		type int32 {
>>                   range "0..7";
>>                 };	=09
>> 		config true;
>> 		description "
>>  0 =E2=80=93 DC power
>>  1 =E2=80=93 Internal Battery
>>  2 =E2=80=93 External Battery
>>  4 =E2=80=93 Power over Ethernet
>>  5 =E2=80=93 USB
>>  6 =E2=80=93 AC (Mains) power
>>  7 =E2=80=93 Solar";
>> 	}
>> =09
>> 	leaf BatteryLevel {
>> 		extensions:LWM2M_Resource_ID "9";
>> 		type int32 {
>>             range "0..100";
>>         };
>> 		units percent;
>> 		config false;
>> 		description "Contains the current battery level as a percentage (wit=
h
>> a range from 0 to 100). This value is only valid when the value of
>> Available Power Sources Resource is 1.";
>> 	}
>> =09
>> 	leaf MemoryFree {
>> 		extensions:LWM2M_Resource_ID "10";
>> 		type int32;
>> 		units KB;
>> 		config false;
>> 		description "Estimated current available amount of storage space whi=
ch
>> can store data and software in the LWM2M Device (expressed in kilobyte=
s).";
>> 	}
>> =09
>> 	leaf CurrentTime {
>> 		extensions:LWM2M_Resource_ID "13";
>> 		type timestamp;
>> 		units KB;
>> 		config false;
>> 		description "Current UNIX time of the LWM2M Client. The LWM2M Client=

>> should be responsible to increase this time value as every second
>> elapses. The LWM2M Server is able to write this Resource to make the
>> LWM2M Client synchronized with the LWM2M Server.";
>> 	}
>> =09
>> }
>>
>> ----
>>
>> The problem I have is to find out whether Yang is able to also describ=
e
>> the interaction model of OMA LWM2M. I believe the current understandin=
g
>> is that this is not possible without some extensions. Please correct m=
e.
>>
>> Ciao
>> Hannes
>>
>>
>> On 04/24/2016 09:28 PM, Carsten Bormann wrote:
>>> Hi Juergen,
>>>
>>> trying to read your message -- are you just commenting on the side
>>> conversation here or is this also a comment on the adoption call?
>>>
>>> Gr=C3=BC=C3=9Fe, Carsten
>>>
>>>
>>> Juergen Schoenwaelder wrote:
>>>> On Thu, Apr 21, 2016 at 05:34:50PM +0000, Michel Veillette wrote:
>>>>> First, LWM2M have its own modeling language encoded in xml.
>>>>> A file like "OMA-SUP-XML_LWM2M_Security-V1_0-20131210-C" is not fun=
damentally different than something than can be named security.yang.
>>>>> A simple xml transform can probably do the conversion between the t=
wo without any lost.
>>>>> LWM2M just have a simpler (subset) modeling language.
>>>>>
>>>>
>>>> These are pretty bold statements. Claiming something is simple and
>>>> knowing something is simple are sometimes different things. Have you=

>>>> worked throught the details? Is there a decent public definition of
>>>> the 'simpler (subset) modeling language'? And with public I mean
>>>> public, not hidden behind all sorts of registration walls.
>>>>
>>>> /js
>>>>
>>>
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>>
>=20
>=20
>=20


--u6qICgIH4qh26M2ENdBv4XGamiE8Gr5cq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXHfmHAAoJEGhJURNOOiAtrnIH/R4YtPyMlajRc0VlhLYnIMTO
Mpz70SbKitFuXta8YFGFGJv6MXb63TBHUuTonptRY8Upa4X6gkVfRYPRcBFRA/8U
kNeC2PfB3mnTtvvC7XKOry3AgM4NeiFXuDfg25iE9nWmPUdAcqRLzE5n5Pjo/69Z
CLAXpZSURGkE2L8TmOZ1y0gbbaXgfEHZgIaxAOSeSVebalmsmGyB++++khyOSh5y
KSr8G5CoKvblExHaZsEwhJ5Q11svyBdPvdjIfP+fbGm18WJhhcamOOoGVyB4hQG7
efwGZh5E1+0p6QlBkhhJgA1I2oyO14dIK7A+BQjPfl3SAo5CNo07dLX/xUum12w=
=qSIN
-----END PGP SIGNATURE-----

--u6qICgIH4qh26M2ENdBv4XGamiE8Gr5cq--


From nobody Mon Apr 25 04:59:44 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DADE12D197 for ; Mon, 25 Apr 2016 04:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8G0OjAnnT5D for ; Mon, 25 Apr 2016 04:59:40 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 59B5012D15B for ; Mon, 25 Apr 2016 04:59:40 -0700 (PDT)
Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 3DFB3F040F069; Mon, 25 Apr 2016 11:59:37 +0000 (GMT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u3PBxcsp024229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Apr 2016 11:59:39 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u3PBxcPl032308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Apr 2016 11:59:38 GMT
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.246]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 25 Apr 2016 07:59:38 -0400
From: "Carey, Timothy (Nokia - US)" 
To: EXT Hannes Tschofenig 
Thread-Topic: CON usage with CoAP over TCP
Thread-Index: AQHRnHK+2DAdgAKToEeukKJi0gtuLp+ampEQ
Date: Mon, 25 Apr 2016 11:59:38 +0000
Message-ID: <9966516C6EB5FC4381E05BF80AA55F77012A6494CF@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <5719E3B0.5050001@gmx.net>
In-Reply-To: <5719E3B0.5050001@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] CON usage with CoAP over TCP
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Apr 2016 11:59:43 -0000

SGFubmVzLA0KDQpZZXMgLSBJdCBkb2VzIHJlc29sdmUgdGhlIGlzc3VlIHdpdGggQ09OLg0KDQpC
UiwNClRpbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRVhUIEhhbm5lcyBU
c2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldF0gDQpTZW50OiBGcmlk
YXksIEFwcmlsIDIyLCAyMDE2IDM6NDEgQU0NClRvOiBDYXJleSwgVGltb3RoeSAoTm9raWEgLSBV
UykNCkNjOiBjb3JlQGlldGYub3JnIFdHDQpTdWJqZWN0OiBDT04gdXNhZ2Ugd2l0aCBDb0FQIG92
ZXIgVENQDQoNClRpbSwNCg0KcGxlYXNlIGRvdWJsZS1jaGVjayB3aGV0aGVyIHlvdSBhZ3JlZSB0
aGF0IHRoZSBuZXcgZHJhZnQgc3VibWlzc2lvbiBhbmQgdGhlIGNoYW5nZSBvZiB0aGUgZW5jb2Rp
bmcgb2YgdGhlIGxlbmd0aCBmb3JtYXQgaW5kZWVkIGFkZHJlc3NlZCB0aGUgaXNzdWUgeW91IHJh
aXNlZC4gSGVyZSBpcyB0aGUgbGluayB0byB0aGUgaXNzdWU6DQpodHRwczovL3RyYWMudG9vbHMu
aWV0Zi5vcmcvd2cvY29yZS90cmFjL3RpY2tldC8zOTcjY29tbWVudDoxDQoNCkNpYW8NCkhhbm5l
cw0KDQo=


From nobody Tue Apr 26 04:15:06 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C29212D12D; Tue, 26 Apr 2016 04:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 Kd3V26aeMbAs; Tue, 26 Apr 2016 04:15:03 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 E622A12D093; Tue, 26 Apr 2016 04:15:03 -0700 (PDT)
Received: from localhost ([::1]:48463 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1av0wu-0003Cr-U8; Tue, 26 Apr 2016 04:14:41 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Tue, 26 Apr 2016 11:14:36 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/395#comment:2
Message-ID: <069.de8ed6e31b3029b66aff22f08a3e55b7@trac.tools.ietf.org>
References: <054.c9e708f420e3b5d1c3d469cf6a66a31c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 395
In-Reply-To: <054.c9e708f420e3b5d1c3d469cf6a66a31c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160426111503.E622A12D093@ietfa.amsl.com>
Resent-Date: Tue, 26 Apr 2016 04:15:03 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #395 (coap-tcp-tls): Session resumption
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 11:15:05 -0000

#395: Session resumption


Comment (by Hannes.Tschofenig@gmx.net):

 Here is a summary of the session resumption (for CoAP over TCP).

 MQTT allows a client to terminate a TCP connection and to reconnect at a
 later time to then receive buffered data from the server side.

 For CoAP over TCP the proposal is to keep implementation complexity
 simpler by using the following policy: whenever a TCP connection is
 terminated then all state information is dumped. Caching of application
 layer messages is still possible using dedicated concepts, for example
 with queue mode (introduced by a mirror server).

 The recommendation is therefore not to make any changes in the document
 (or alternatively highlight that this functionality is not provided even
 thought it wouldn't normally be assumed to exist anyway).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Tue Apr 26 05:47:42 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90812D0DD; Tue, 26 Apr 2016 05:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 uUL0DdeCJIEM; Tue, 26 Apr 2016 05:47:37 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 48F6E12D0A5; Tue, 26 Apr 2016 05:47:37 -0700 (PDT)
Received: from localhost ([::1]:51874 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1av2Ou-0007Ri-Ma; Tue, 26 Apr 2016 05:47:36 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Tue, 26 Apr 2016 12:47:36 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/394#comment:1
Message-ID: <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org>
X-Trac-Ticket-ID: 394
In-Reply-To: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160426124737.48F6E12D0A5@ietfa.amsl.com>
Resent-Date: Tue, 26 Apr 2016 05:47:37 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 12:47:41 -0000

#394: Ping/pong


Comment (by Hannes.Tschofenig@gmx.net):

 Here is the story for adding keep-alive functionality to the CoAP over TCP
 document.

 After reaching out to folks measuring TCP usage I was told that the use of
 TCP keepalive messages is often unreliable since network operators deploy
 middleboxes, which suppress these messages.

 For this reason we are suggesting to add a ping/pong message to the CoAP
 over TCP document. Here is how this could look like.

 First, we define a new CoAP Method Codes (for the request) and CoAP
 Response Codes (for the responses). Let us give them new numbers, such as
 7.01 (for PING) and 7.02 (for PONG).

 Here is an example message exchange:
 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |   NON            |
                            | GET /temperature |
                            |   (Token 0x74)   |
                            +----------------->|
                            |                  |
                            |   NON [0x23bc]   |
                            |   2.05 Content   |
                            |   (Token 0x74)   |
                            |     "22.5 C"     |
                            |<-----------------+
                            |                  |
                            |      ......      |
                            |   time passes    |
                            |      ......      |
                            |                  |
                            |7.03 Ping         |
                            |(Token 0x7f)      |
                            +----------------->|
                            |                  |
                            |7.02 Pong         |
                            |(Token 0x7f)      |
                            |<-----------------+
                            |                  |
                            |  <--- TCP --->   |
                            |  Conn. Teadown   |
 }}}

 The PING packet would look as follows:

 {{{
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x01     |      0xe1     |      0x7f     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Len   =    0 ------>  0x01
     TKL   =    1 ___/
     Code  =  7.01     --> 0xe1
     Token =               0x7f

            Figure: PING Encoding Example.
 }}}

 The PONG packet has the following structure:

 {{{
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      0x01     |      0xe2     |      0x7f     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Len   =    0 ------>  0x01
     TKL   =    1 ___/
     Code  =  7.02     --> 0xe2
     Token =               0x7f

            Figure: PONG Encoding Example.
 }}}

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  protocol     |      Status:  new
  enhancement            |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Tue Apr 26 06:15:04 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09A12D147 for ; Tue, 26 Apr 2016 06:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 JqUfT_iDTea2 for ; Tue, 26 Apr 2016 06:14:59 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D858112D130 for ; Tue, 26 Apr 2016 06:14:58 -0700 (PDT)
Received: from localhost ([::1]:53218 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1av2pO-0001gY-Jf; Tue, 26 Apr 2016 06:14:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-http-mapping@tools.ietf.org, akbar.rahman@interdigital.com
X-Trac-Project: core
Date: Tue, 26 Apr 2016 13:14:58 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/401
Message-ID: <069.73f5d27f1b947907c329ff6c0cb6514a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 401
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-http-mapping@tools.ietf.org, akbar.rahman@interdigital.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-http-mapping@ietf.org
Resent-Message-Id: <20160426131458.D858112D130@ietfa.amsl.com>
Resent-Date: Tue, 26 Apr 2016 06:14:58 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #401 (http-mapping): Update to also cover forward and interception proxy cases
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:15:03 -0000

#401: Update to also cover forward and interception proxy cases

 Clarify that the scope of draft is primarily Reverse HC Proxy but that it
 also covers generic protocol translation aspects that apply as well to
 Forward and Interception HC Proxy
                â–  e.g. Response status mapping & content format mapping
 apply to all types of proxies



 This was discussed in IETF-95 and on the mailing list as per

 https://www.ietf.org/mail-archive/web/core/current/msg07035.html

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-core-http-
  akbar.rahman@interdigital.com      |  mapping@tools.ietf.org
     Type:  protocol enhancement     |     Status:  new
 Priority:  major                    |  Milestone:
Component:  http-mapping             |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
core 


From nobody Tue Apr 26 06:22:30 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD71112D1A5 for ; Tue, 26 Apr 2016 06:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.252
X-Spam-Level: 
X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665, WEIRD_PORT=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 9Dp8DxKoIphQ for ; Tue, 26 Apr 2016 06:22:27 -0700 (PDT)
Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E080812D130 for ; Tue, 26 Apr 2016 06:22:26 -0700 (PDT)
X-ASG-Debug-ID: 1461676944-06daaa10887ec40001-aa7cYp
Received: from NISSONITE.InterDigital.com (nissonite.interdigital.com [10.2.64.252]) by smtp-in1.interdigital.com with ESMTP id dJjIn3YkdDtUUD8i (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Apr 2016 09:22:24 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Tue, 26 Apr 2016 09:22:23 -0400
From: "Rahman, Akbar" 
To: Hannes Tschofenig , Carsten Bormann , "core@ietf.org WG" 
Thread-Topic: [core] Comments on proposed changes to draft-ietf-core-http-mapping
X-ASG-Orig-Subj: RE: [core] Comments on proposed changes to draft-ietf-core-http-mapping
Thread-Index: AdGULkDwKoTQS8fcTZW9boOCJcyTOwHDh74AASBv49A=
Date: Tue, 26 Apr 2016 13:22:22 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAB204E@NABESITE.InterDigital.com>
References: <36F5869FE31AB24485E5E3222C288E1F5BAA8E0E@NABESITE.InterDigital.com> <5717A2BA.3020404@gmx.net>
In-Reply-To: <5717A2BA.3020404@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.2.251]
x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Barracuda-Connect: nissonite.interdigital.com[10.2.64.252]
X-Barracuda-Start-Time: 1461676944
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 7783
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.50
X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO, WEIRD_PORT
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29070 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header 0.50 WEIRD_PORT             URI: Uses non-standard port number for HTTP
Archived-At: 
Subject: Re: [core] Comments on proposed changes to draft-ietf-core-http-mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:22:29 -0000

SGkgSGFubmVzL0NhcnN0ZW4sDQoNCg0KVGhhbmtzLiAgU2luY2UgdGhlIHR3byB3ZWVrIHJldmll
dyBwZXJpb2QgaGFzIHBhc3NlZCBhbmQgd2UgZGlkbid0IGdldCBhbnkgb2JqZWN0aW9ucywgd2Ug
d2lsbCB1cGRhdGUgdGhlIGRyYWZ0IHNob3J0bHkgYXMgcGVyIHJlY2VudGx5IGNyZWF0ZWQgdGlj
a2V0ICM0MDEuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOmhhbm5lcy50c2No
b2ZlbmlnQGdteC5uZXRdDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDIwLCAyMDE2IDExOjQwIEFN
DQpUbzogUmFobWFuLCBBa2JhciA8QWtiYXIuUmFobWFuQEludGVyRGlnaXRhbC5jb20+OyBDYXJz
dGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IGNvcmVAaWV0Zi5vcmcgV0cgPGNvcmVAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIENvbW1lbnRzIG9uIHByb3Bvc2VkIGNoYW5nZXMgdG8g
ZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZw0KDQpIaSBBa2JhciwNCg0KY2hhbmdpbmcgdGhl
IHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byBpbmNsdWRlIGZvcndhcmQgYW5kIHJldmVyc2UgcHJv
eHkgZnVuY3Rpb25hbGl0eSwgYXMgZGlzY3Vzc2VkIGluIEJBLCBpcyBmaW5lIGZvciBtZS4NCg0K
Q2lhbw0KSGFubmVzDQoNCg0KT24gMDQvMTEvMjAxNiAxMDoyNyBQTSwgUmFobWFuLCBBa2JhciB3
cm90ZToNCj4gSGkgQWxsLA0KPg0KPg0KPiBBdCBJRVRGLTk1IChCdWVub3MgQWlyZXMpIHdlIGRp
c2N1c3NlZCBtb2RpZnlpbmcgZHJhZnQtaWV0Zi1jb3JlLWh0dHAtbWFwcGluZyB0bzoNCj4NCj4g
ICAgICAgIENsYXJpZnkgdGhhdCB0aGUgc2NvcGUgb2YgZHJhZnQgaXMgcHJpbWFyaWx5IFJldmVy
c2UgSEMgUHJveHkgYnV0IHRoYXQgaXQgYWxzbyBjb3ZlcnMgZ2VuZXJpYyBwcm90b2NvbCB0cmFu
c2xhdGlvbiBhc3BlY3RzIHRoYXQgYXBwbHkgYXMgd2VsbCB0byBGb3J3YXJkIGFuZCBJbnRlcmNl
cHRpb24gSEMgUHJveHkNCj4gICAgICAgICAgICAgICAg4pagIGUuZy4gUmVzcG9uc2Ugc3RhdHVz
IG1hcHBpbmcgJiBjb250ZW50IGZvcm1hdCBtYXBwaW5nDQo+IGFwcGx5IHRvIGFsbCB0eXBlcyBv
ZiBwcm94aWVzDQo+DQo+DQo+IFNwZWNpZmljYWxseSBzZWUgcGcuIDcwLTcxIG9mIHRoZSBGMkYg
cHJlc2VudGF0aW9uIHNsaWRlcyB0aGF0IHByZXNlbnRzIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm9w
b3NlZCBjaGFuZ2VzOg0KPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9z
bGlkZXMvc2xpZGVzLTk1LWNvcmUtMC5wZGYNCj4NCj4NCj4gV2UgaGFkIGdvb2Qgc3VwcG9ydCBk
dXJpbmcgdGhlIEYyRiBtZWV0aW5nIHRvIG1ha2UgdGhlc2UgY2hhbmdlcy4gIERvZXMgYW55b25l
IGhhdmUgYW55IGlzc3VlcyB3aXRoIHRoaXMgYXBwcm9hY2g/ICBJZiB5b3UgZG8gcGxlYXNlIHdy
aXRlIGJhY2sgdG8gdGhlIGxpc3QuICBJZiB3ZSBoYXZlIG5vdCByZWNlaXZlZCBhbnkgY29tbWVu
dHMgYnkgQXByaWwgMjIgd2Ugd2lsbCBhc3N1bWUgdGhhdCB0aGlzIGRlY2lzaW9uIGlzIHN1cHBv
cnRlZCBieSB0aGUgV0cgYW5kIHdpbGwgcHJvY2VlZCB0byBtYWtlIHRoZSBjaGFuZ2VzIHNvIHRo
YXQgd2UgY2FuIHN0YXJ0IHRoZSBuZXcgV0dMQy4NCj4NCj4NCj4NCj4gVGhhbmtzLA0KPg0KPg0K
PiBBa2Jhcg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjb3Jl
IFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3Jt
YW5uDQo+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAwOSwgMjAxNiAxMDowMCBBTQ0KPiBUbzogY29y
ZUBpZXRmLm9yZyBXRyA8Y29yZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogW2NvcmVdIFN1bW1hcnkg
b2Ygc2Vjb25kIG1lZXRpbmcgYXQgSUVURjk1DQo+DQo+IC4uLiBhbmQgaGVyZSBpcyBteSBzdW1t
YXJ5IG9mIHRoZSBGcmlkYXkgcmVzdWx0cy4NCj4NCj4gQWdhaW4sIHBsZWFzZSBzZW5kIGluIGZp
eGVzIGFuZCBhZGRpdGlvbnM7IHRoZSByYXcgZGV0YWlscyBhcmUgc3RpbGwNCj4gYXQgdGhlIHNh
bWUgc2l0ZToNCj4gaHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1p
ZXRmLTk1LWNvcmUNCj4gQmlnIHRoYW5rcyB0byB0aGUgbm90ZSB0YWtlcnMhDQo+DQo+IE9uIEZy
aWRheToNCj4NCj4gKiBIYW5kb2ZmIG9mIHRoZSBCYXRvbjogQmFycnkgTGVpYmEgZ2F2ZSBoaXMg
ZmFyZXdhbGwgYXMgQ29SRSdzDQo+IHJlc3BvbnNpYmxlIEFEOyBncmVhdCBhcHBsYXVzZSBvZiB0
aGUgV0cuDQo+ICogRm9yIHRoZSByZXNvdXJjZSBkaXJlY3RvcnkgKFJEKSBhbmQgcmVsYXRlZCBk
b2N1bWVudHMsIHdlIGFyZSBhaW1pbmcNCj4gYXQgV0dMQyBiZWZvcmUgSnVseSAxc3Qgc28gd2Ug
Y2FuIGRpc2N1c3MgdGhlIG91dGNvbWUgaW4gQmVybGluIGFuZA0KPiBzaGlwIHNvb24gYWZ0ZXIu
ICBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgdGhpbmdzIHRvIGRvLCBtYW55IG9mIHdoaWNoDQo+IGFy
ZSBvbiB0aGUgZWRpdG9yaWFsIGxldmVsIChzZWUgc2xpZGVzLCBidXQgYWxzbyBBa2JhcidzICJh
ZHZhbmNlZA0KPiBSRCIgZG9jdW1lbnQ7IHdlIHdpbGwgbm90IHRyeSB0byBwdXQgbWlycm9yIHNl
cnZlci9wdWJzdWIgc3VwcG9ydCBpbg0KPiB0aGUgUkQgZG9jdW1lbnQgbm93LCB0aG91Z2gpLiBU
aGUgaXNzdWVzIHdpbGwgbWFuYWdlZCBvbiB0aGUgV0cNCj4gdHJhY2tlci4NCj4gKiBUaGVyZSB3
YXMgaW4tcm9vbSBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQtdmFuZGVyc3Rvay1jb3JlLWV0Y2gt
MDANCj4gYXMgYSBXRyBkb2N1bWVudC4gIFRoaXMgaXMgbmVlZGVkIHRvIGtlZXAgUEFUQ0ggaW4g
dGhlIFJELCBidXQgYWxzbw0KPiBmb3IgdGhlIG1hbmFnZW1lbnQgd29yayAoYmVsb3cpLiAgVG8g
YmUgdmVyaWZpZWQgb24gdGhlIG1haWxpbmcgIGxpc3QuDQo+ICogY29yZS1saW5rcy1qc29uIGFs
c28gaXMgaW4gdGhlIHNhbWUgY2x1c3RlciAoV0dMQyBiZWZvcmUgSnVseSAxc3QpLg0KPiAgSGFu
bmVzIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBSRkM3MzkwIHBhcnRzIHNlcGFyYXRlZCBvdXQgZnJv
bSB0aGUNCj4gIFJGQzY2OTAgcGFydCB0aGF0IHdlIGFyZSBhYm91dCBmb3IgUkQuICBUaGUgVE9E
T3MgaW4gdGhlIGRvY3VtZW50DQo+IG5lZWQgdG8gYmUgdGlja2VkIG9mZi90cmFja2VyaXplZC4N
Cj4gKiBUaGVyZSB3aWxsIGJlIGEgMm5kIFdHTEMgZm9yIGNvcmUtaHR0cC1tYXBwaW5nIGFmdGVy
IHRoZSBjb21tZW50cw0KPiBhcmUgaW5jb3Jwb3JhdGVkICgtMTApLg0KPiAqIGNvcmUtaW50ZXJm
YWNlcyBtYXkgaGF2ZSBiZWVuIGFkb3B0ZWQgdG9vIGVhcmx5IGFuZCByZXF1aXJlcyBhIG1ham9y
DQo+IG92ZXJoYXVsLCBzZXBhcmF0aW5nIG91dCB0aGUgbW9yZSBzcGVjdWxhdGl2ZSBtYXRlcmlh
bCAoc29tZSBvZiAgd2hpY2gNCj4gaXMgVDJUUkcgbWF0ZXJpYWwpLiAgSXQgc2hvdWxkIGJlIG1h
ZGUgdmVyeSBjbGVhciB0aGF0IHRoaXMgIGRlc2NyaWJlcw0KPiBvbmUgd2F5IG9mIHVzaW5nIENv
QVAgKHdoaWNoIGhhcyBpbmRlZWQgYmVlbiBwaWNrZWQgdXAgaW4gIHZhcmlvdXMNCj4gd2F5cyBi
eSBvdGhlciBTRE9zKSwgbm90IHRoZSBwcmVzY3JpYmVkIHdheS4gIE1hdHRoaWFzIHdpbGwgIGhl
bHANCj4gTWljaGFlbCB0byBkbyB0aGUgc2VwYXJhdGlvbi4NCj4gKiBUaGUgd29yayBvbiBtYW5h
Z2VtZW50IG9mIGNvbnN0cmFpbmVkIGRldmljZXMgaGFzIGNvbnZlcmdlZCAoIkNPTUkNCj4gd2l0
aCBDT09MIikuICBUaGUgeWFuZy1jYm9yIGRyYWZ0IGlzIHJlYWR5IGZvciBhbiBhZG9wdGlvbiBj
YWxsLCBidXQNCj4gbm90IGVub3VnaCBwZW9wbGUgaGFkIHJlYWQgaXQgeWV0IHRvIGRvIGFuIGlu
LXJvb20gYWRvcHRpb24gY2hlY2suDQo+ICBUaGUgb3RoZXIgZHJhZnRzIHdpbGwgdW5kZXJnbyBt
ZXJnZXIvcmVzdHJ1Y3R1cmluZyB3b3JrIGJhc2VkIG9uDQo+IHRoaXMgd2VlaydzIGRpc2N1c3Np
b25zIGFuZCBzaG91bGQgdGhlbiBiZWNvbWUgcmVhZHkgZm9yIGFkb3B0aW9uLg0KPiAgVGhpcyB3
b3JrIGlzIGV4cGxpY2l0bHkgY292ZXJlZCBieSBvdXIgY2hhcnRlciAod2hpY2ggYWxzbyBjYWxs
cyBvdXQNCj4gTFdNMk0gbWFuYWdlbWVudCBhcyBhIHJlbGF0ZWQgYXBwcm9hY2ggdGhhdCB3ZSB3
aWxsIGNvbnRpbnVlIHRvDQo+IHN1cHBvcnQgYXMgbmVlZGVkKSwgYW5kIHdlIHdpbGwgaW1wbGlj
YXRlIE5FVE1PRC9ORVRDT05GIGludG8gZXZlcnkNCj4gc3RlcCB3ZSBhcmUgdGFraW5nLiAgVGhl
IGF1dGhvciB0ZWFtIGludml0ZXMgdGhlIFdHIHRvIGl0cyBiaS13ZWVrbHkNCj4gcGhvbmUgbWVl
dGluZ3MgKHRvIGJlIGFubm91bmNlZCBvbiBjb3JlIG1haWxpbmcgbGlzdCkuDQo+ICogVGhlIHdv
cmsgb24gT2JqZWN0IFNlY3VyaXR5IGZvciBDT0FQIChPU0NPQVApIGlzIHByb2dyZXNzaW5nIG5p
Y2VseS4NCj4gIEEgY29tcGxldGUgZHJhZnQgY2FuIGJlIGV4cGVjdGVkIGZvciBCZXJsaW4uDQo+
DQo+DQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4NCj4NCj4gQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0K
Pj4gSGVyZSBpcyBteSBzdW1tYXJ5IG9mIHdoYXQgd2UgZGlkIG9uIFR1ZXNkYXkuDQo+PiBGaXhl
cy9hZGRpdGlvbnMgd2VsY29tZTsgZGV0YWlscyBhcmUgaW4gdGhlIGRyYWZ0IG1pbnV0ZXMgYXQN
Cj4+IGh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0Zi05NS1j
b3JlDQo+Pg0KPj4gT24gVHVlc2RheToNCj4+DQo+PiAqIEFuZHJldyBpbmRpY2F0ZWQgdGhhdCBo
ZSBwbGFucyB0byBzdGVwIGRvd24gYXMgYSBXRyBjaGFpciBhbmQgdGhhdA0KPj4gICB0aGUgQURz
IGFyZSBsb29raW5nIGZvciBhIHJlcGxhY2VtZW50Lg0KPj4gKiBBcyBwZXJpb2RpY2FsbHksIHRo
ZSBBRCBpcyBjaGFuZ2luZzsgdGhpcyB0aW1lIGZyb20gYSBncmF5YmVhcmQNCj4+ICAgKEJhcnJ5
KSB0byBhIGJsYWNrYmVhcmQgKEFsZXhleSkuDQo+PiAqIFRoZSBjaGFpcnMgYXBvbG9naXplIGZv
ciB0aGUgaW5mcmVxdWVudGx5IHVwZGF0ZWQgbWlsZXN0b25lczsgZml4aW5nDQo+PiAgIHRoZW0g
aXMgdXAgbmV4dC4NCj4+ICogZHJhZnQtaWV0Zi1jb3JlLWJsb2Nr4oCTMTkgaXMgaW4gSUVTRyBF
dmFsdWF0aW9uLCB0ZWxlY2hhdCBkYXRlIGlzDQo+PiAgIDIwMTbigJMwNOKAkzIxLg0KPj4gKiBo
ZWFkcy11cCBmb3IgbmV3IGluZGl2aWR1YWwgZHJhZnRzOiBkcmFmdC1raXZpbmVuLTgwMi0xNS1p
ZSBhbmQNCj4+ICAgZHJhZnQtYm9ybWFubi02bG8tY29hcC04MDItMTUtaWUuDQo+PiAqIENvQVAg
b3ZlciBUQ1AgcmVjZWl2ZWQgZXh0ZW5zaXZlIGRpc2N1c3Npb24uICBSZXN1bHRzIChhbGwgdG8g
YmUNCj4+ICAgY29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QpOg0KPj4gICAqICMzOTY6IFdl
IHJldmVydCB0aGUgZGVjaXNpb24gaW4gWW9rb2hhbWEgYW5kIGdvIHdpdGggYWx0ZXJuYXRpdmUN
Cj4+ICAgICBMMy4gIFByb2NlZHVyYWxseSwgdGhlIHBhaW4gb2YgdGhpcyByZXZlcnNhbCBpcyBi
YWxhbmNlZCBieSB0aGUNCj4+ICAgICByZWR1Y2VkIHBhaW4gb2Ygbm90IGhhdmluZyB0byBjb252
aW5jZSBPQ0YgdG8gY2hhbmdlIHRoZWlyDQo+PiAgICAgc3BlY2lmaWNhdGlvbi4gIFRlY2huaWNh
bGx5LCBMMyBpcyBtb3JlIG9wZW4gdG8gZXZvbHZpbmcgaWRlYXMgYWJvdXQNCj4+ICAgICBtZXNz
YWdlIHNpemVzLiAgSW4gYW55IGNhc2UsIHRoZXJlIGlzIG5vIGludGVudCB0byBtb2RpZnkgb3IN
Cj4+ICAgICByZXZva2Ugc2VjdGlvbiA0LjYgb2YgUkZDIDcyNTIgYXQgdGhpcyB0aW1lLg0KPj4g
ICAqIFdlIHdpbGwgbmVlZCB0byBleGFtaW5lIHRoZSB2YXJpb3VzIHByb3Bvc2FscyB0byBhZGQg
c2lnbmFsaW5nIHRvDQo+PiAgICAgdGhlIFRDUCBjb25uZWN0aW9uIChzZXR0aW5ncywgcGluZy9w
b25nLCByZWxlYXNlL2Fib3J0KS4NCj4+ICAgICBTaWduYWxpbmcgbWVzc2FnZXMgKDcueHgpIGlz
IG9uZSBwb3NzaWJsZSBtZWNoYW5pc20gZm9yIGRvaW5nIHRoYXQuDQo+PiAgICogIzM4NyAoQUxQ
Tik6IFdlIHJlYWxseSBuZWVkIHRvIG1ha2UgYSBkZWNpc2lvbiBoZXJlLg0KPj4gICAqIFdlYnNv
Y2tldHM6IEZvciBtZXJnaW5nIHRoZSB3ZWJzb2NrZXRzIGRyYWZ0IGludG8gdGhlIFRDUC9UTFMg
V0cNCj4+ICAgICBkb2N1bWVudCAod2l0aCB0aGUgd2Vic29ja2V0cyBzcGVjaWZpYyBwYXJ0cyBn
b2luZyB0byBhbg0KPj4gICAgIGFwcGVuZGl4KSwgdGhlIGF1dGhvcnMgb2YgYm90aCBkcmFmdHMg
d2lsbCBkaXNjdXNzIHRoZSBtZXJnZS4NCj4+ICogTXVsdGktaG9wIFNlY3VyaXR5OiBJbml0aWFs
IGRpc2N1c3Npb24gb2YNCj4+ICAgZHJhZnQtaGFydGtlLWNvcmUtZTJlLXNlY3VyaXR5LXJlcXMu
DQo+PiAgICogSXQgaXMgbW9yZSB3ZWxsLWRlZmluZWQgd2hhdCBpcyBiZWluZyBwcm90ZWN0ZWQg
aW4gYQ0KPj4gICAgIHJlcXVlc3QtcmVzcG9uc2UgdGhhdCBzcGFucyBhIHByb3h5IHRoYW4gd2l0
aCBhIHB1Yi1zdWIgYnJva2VyLg0KPj4gICAqIFRoZSBjdXJyZW50IHNldCBvZiBzY2VuYXJpb3Mg
ZG9lcyBub3QgaW5jbHVkZSB0aGUgY2FzZSB0aGF0DQo+PiAgICAgc2VjdXJpdHkgc2VydmljZXMg
YXJlIGJlaW5nIHBlcmZvcm1lZCBieSB0aGUgaW50ZXJtZWRpYXJ5Lg0KPj4gICAgIE1hbnkgc3Vj
aCBzY2VuYXJpb3MgYXJlIGNvbmNlaXZhYmxlOyB3aGljaCBvbmVzIGhhdmUgc2VyaW91cyB1c2UN
Cj4+ICAgICBjYXNlcz8NCj4+ICAgKiBNdWx0aWNhc3QgKG9yLCBtb3JlIGdlbmVyYWxseSwgZ3Jv
dXAgY29tbXVuaWNhdGlvbikgaXMgbm90IHlldA0KPj4gICAgIGJlaW5nIGNvbnNpZGVyZWQuDQo+
PiAqIERhdGEgRm9ybWF0czogV0cgdG8gYWRvcHQgU2VuTUwgKHRvIGJlIGNvbmZpcm1lZCBvbiB0
aGUgbWFpbGluZw0KPj4gICBsaXN0KS4gIEFmdGVyIGEgYml0IG9mIEJyb3duaWFuIG1vdGlvbiwg
dGhlIFdHIGlzIG5vdyBoYXBweSB3aXRoIHRoZQ0KPj4gICB3YXkgdGhlIGRhdGEgaXMgZm9ybWF0
dGVkIGluIC0wNiAoYmFzZSByZWNvcmQgd2l0aCBkYXRhLCB6ZXJvIG9yDQo+PiAgIG1vcmUgcmVj
b3JkcyB3aXRoIG1vcmUgZGF0YSkuICBUaGUgYWRkaXRpb24gb2YgbGlua3MgaW4gdGhlIGRhdGEg
aXMNCj4+ICAgdG8gYmUgZG9uZSBieSByZWdpc3RlcmluZyBhIHNlbm1sIGxhYmVsIGluIGNvcmUt
bGlua3MtanNvbg0KPj4gICAoInJldmVyc2luZyB0aGUgYXJyb3cgb2YgZGVwZW5kZW5jeSIpLg0K
Pj4NCj4+IEZyaWRheSBtZWV0aW5nIHVwY29taW5nLg0KPj4NCj4+IEdyw7zDn2UsIENhcnN0ZW4N
Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+IGNvcmVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPj4NCj4+DQo+DQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+
IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j
b3JlDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo+DQoNCg==


From nobody Tue Apr 26 06:22:32 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5970312D130; Tue, 26 Apr 2016 06:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 TyT2leNAebk1; Tue, 26 Apr 2016 06:22:28 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 2F39712D152; Tue, 26 Apr 2016 06:22:28 -0700 (PDT)
Received: from localhost ([::1]:53716 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1av2wX-0000Z4-RE; Tue, 26 Apr 2016 06:22:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, hartke@tzi.org
X-Trac-Project: core
Date: Tue, 26 Apr 2016 13:22:21 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/391#comment:3
Message-ID: <069.8555b2a85bcb8b9bd42a101b66d46db5@trac.tools.ietf.org>
References: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org>
X-Trac-Ticket-ID: 391
In-Reply-To: <054.b6ac939ca38bdca0e98e9f1ec2980928@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, hartke@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160426132228.2F39712D152@ietfa.amsl.com>
Resent-Date: Tue, 26 Apr 2016 06:22:28 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #391 (coap-tcp-tls): Server name indication
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:22:29 -0000

#391: Server name indication


Comment (by Hannes.Tschofenig@gmx.net):

 To indicate the name of a server in a CoAP over TCP solution scenario the
 following approaches are possible:

 1) Indicate the host option in every request
 2) Indicate the host option during a connection setup phase

 Given the connection-oriented nature of TCP it certainly makes sense to
 provide the server name indication at the beginning of the connection
 setup, similarly to what Websockets and TLS/DTLS does.

 Here is how this could look like.

 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.03 ClientHello  |
                            |+ SNI: example.com|
                            +----------------->|
                            |                  |
                            |7.04 ServerHello  |
                            |<-----------------+
                            |                  |
                            |   NON            |
                            | GET /temperature |
                            |   (Token 0x74)   |
                            +----------------->|
                            |                  |
                            |   NON [0x23bc]   |
                            |   2.05 Content   |
                            |   (Token 0x74)   |
                            |     "22.5 C"     |
                            |<-----------------+
                            |                  |
                            |      ......      |
                            |   time passes    |
                            |      ......      |
                            |                  |
                            |                  |
                            |  <--- TCP --->   |
                            |  Conn. Teardown  |
 }}}

 There are two aspects worth highlighting:

 1) There is an initial handshake between the client and the server using
 newly defined CoAP Method Codes / CoAP Response Codes (7.02 & 7.03 in our
 example).

 2) The ClientHello message contains information about the Server Name
 Indication as a FQDN (similarly to what is done in TLS/DTLS with the SNI
 extension sent in the ClientHello msg).
 This SNI is a new option that needs to be defined.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  other        |      Status:  new
  technical              |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Tue Apr 26 06:33:08 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16D12D0AD for ; Tue, 26 Apr 2016 06:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w27Ld-Y088Py for ; Tue, 26 Apr 2016 06:33:05 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 6CD3E12D0A7 for ; Tue, 26 Apr 2016 06:33:05 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id v188so128927902wme.1 for ; Tue, 26 Apr 2016 06:33:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=2JmddF64+o1iTYsDy2oXJBItNQgnEZwCVEP28d/zNs0=; b=J1ohcu8aHLk2KPhXGXRVnparKpaLy8N8r455kF6MhA5rBafKzKJ6fQJw4SY5xKIbvB y1m3IvXlY080dqfECS2oSEAPsUj5uhqiVOO0QAJewvMd6h38r5AVa7vULnQd4DZ7jkgN W7uQzBwrYwH+15tVUQ2kPV66fKUO6YewWtigwG/+Z+Ofbe7NQmwXPA81JqQAOFgpkQ+d yJi6z3wIw86vY1s1ojjfbjJbD7T55ZT2+/L5rYTyThMC+02aeNl2BIorXryf7oSwGhUe aks5lnbz49Z1Gm8/sMtY1hSZk9S8m/OkPUg/MH48icpF8ULIPTHHmbEx5u3p/G/AFhv+ rD4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2JmddF64+o1iTYsDy2oXJBItNQgnEZwCVEP28d/zNs0=; b=kPju/zlLsFuy3BT+O0XPUAGb6qWDu2FjM+HbZRPqrP13LYPauPPJXHOGiiw9WEpT3y 9ykOPPz5dlMf7sDZRxkp28G0WIwYctIUokhcdYLEjh5HjWvOu3EzF42hiEzMJP+Pqn7+ FbhX1kRcsXQ2tQXFX3S64e7lJ56+C1EVGO0rLQHBzPJVd9ADzfcs0PkcLqfqs+utDuKq oDt3NvDjdDlEbpmO7VjpSF0qFjAxOKeQcVwRT20bXKDL3IuAbkItnOQqK0o9sO7j4dci MhEY6hy0Vemh96KIRYO7UJ4Yq4TFrOLukMdNFMr6uvuHQIGYggnBnVbbOkOUPj2+63Mq TF4A==
X-Gm-Message-State: AOPr4FXlglwvOWK05WIOOnQrTF6HlHMzju6R5wjAR5ihScBj0eDjspcGvZFiEqyk2ZANY95xtOJPZyWgEB8vwQ==
X-Received: by 10.194.134.3 with SMTP id pg3mr3214650wjb.141.1461677583763; Tue, 26 Apr 2016 06:33:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.88.80 with HTTP; Tue, 26 Apr 2016 06:32:44 -0700 (PDT)
In-Reply-To: <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>
From: Julien Vermillard 
Date: Tue, 26 Apr 2016 15:32:44 +0200
Message-ID: 
To: "core@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0122914a280e640531635557
Archived-At: 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:33:07 -0000

--089e0122914a280e640531635557
Content-Type: text/plain; charset=UTF-8

Why not simply using CoAP reset messages as ping ?

https://tools.ietf.org/html/rfc7252

 Provoking a Reset
      message (e.g., by sending an Empty Confirmable message) is also
      useful as an inexpensive check of the liveness of an endpoint
      ("CoAP ping").



--
Julien Vermillard

On Tue, Apr 26, 2016 at 2:47 PM, core issue tracker <
trac+core@zinfandel.tools.ietf.org> wrote:

> #394: Ping/pong
>
>
> Comment (by Hannes.Tschofenig@gmx.net):
>
>  Here is the story for adding keep-alive functionality to the CoAP over TCP
>  document.
>
>  After reaching out to folks measuring TCP usage I was told that the use of
>  TCP keepalive messages is often unreliable since network operators deploy
>  middleboxes, which suppress these messages.
>
>  For this reason we are suggesting to add a ping/pong message to the CoAP
>  over TCP document. Here is how this could look like.
>
>  First, we define a new CoAP Method Codes (for the request) and CoAP
>  Response Codes (for the responses). Let us give them new numbers, such as
>  7.01 (for PING) and 7.02 (for PONG).
>
>  Here is an example message exchange:
>  {{{
>                          Client              Server
>                             |                  |
>                             | <--- TCP --->    |
>                             | Connection Setup |
>                             |                  |
>                             |   NON            |
>                             | GET /temperature |
>                             |   (Token 0x74)   |
>                             +----------------->|
>                             |                  |
>                             |   NON [0x23bc]   |
>                             |   2.05 Content   |
>                             |   (Token 0x74)   |
>                             |     "22.5 C"     |
>                             |<-----------------+
>                             |                  |
>                             |      ......      |
>                             |   time passes    |
>                             |      ......      |
>                             |                  |
>                             |7.03 Ping         |
>                             |(Token 0x7f)      |
>                             +----------------->|
>                             |                  |
>                             |7.02 Pong         |
>                             |(Token 0x7f)      |
>                             |<-----------------+
>                             |                  |
>                             |  <--- TCP --->   |
>                             |  Conn. Teadown   |
>  }}}
>
>  The PING packet would look as follows:
>
>  {{{
>      0                   1                   2
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      0x01     |      0xe1     |      0x7f     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Len   =    0 ------>  0x01
>      TKL   =    1 ___/
>      Code  =  7.01     --> 0xe1
>      Token =               0x7f
>
>             Figure: PING Encoding Example.
>  }}}
>
>  The PONG packet has the following structure:
>
>  {{{
>      0                   1                   2
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      0x01     |      0xe2     |      0x7f     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Len   =    0 ------>  0x01
>      TKL   =    1 ___/
>      Code  =  7.02     --> 0xe2
>      Token =               0x7f
>
>             Figure: PONG Encoding Example.
>  }}}
>
> --
> -------------------------+-------------------------------------------------
>  Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
>   hartke@tzi.org         |  tls@ietf.org
>      Type:  protocol     |      Status:  new
>   enhancement            |   Milestone:
>  Priority:  minor        |     Version:
> Component:  coap-tcp-    |  Resolution:
>   tls                    |
>  Severity:  Active WG    |
>   Document               |
>  Keywords:               |
> -------------------------+-------------------------------------------------
>
> Ticket URL:  >
> core 
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--089e0122914a280e640531635557
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+V2h5IG5vdCBzaW1wbHkgdXNpbmcgQ29BUCByZXNldCBtZXNzYWdlcyBh
cyBwaW5nID88YnI+PGJyPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3
MjUyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzI1MjwvYT48YnI+PHByZSBjbGFz
cz0iIj4gUHJvdm9raW5nIGEgUmVzZXQNCiAgICAgIG1lc3NhZ2UgKGUuZy4sIGJ5IHNlbmRpbmcg
YW4gRW1wdHkgQ29uZmlybWFibGUgbWVzc2FnZSkgaXMgYWxzbw0KICAgICAgdXNlZnVsIGFzIGFu
IGluZXhwZW5zaXZlIGNoZWNrIG9mIHRoZSBsaXZlbmVzcyBvZiBhbiBlbmRwb2ludA0KICAgICAg
KCZxdW90O0NvQVAgcGluZyZxdW90OykuPGJyPjxicj48L3ByZT48YnI+PC9kaXY+PGRpdiBjbGFz
cz0iZ21haWxfZXh0cmEiPjxiciBjbGVhcj0iYWxsIj48ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3Np
Z25hdHVyZSI+PGRpdiBkaXI9Imx0ciI+PGRpdj4tLTxicj5KdWxpZW4gVmVybWlsbGFyZDwvZGl2
PjwvZGl2PjwvZGl2PjwvZGl2Pg0KPGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUs
IEFwciAyNiwgMjAxNiBhdCAyOjQ3IFBNLCBjb3JlIGlzc3VlIHRyYWNrZXIgPHNwYW4gZGlyPSJs
dHIiPiZsdDs8YSBocmVmPSJtYWlsdG86dHJhYytjb3JlQHppbmZhbmRlbC50b29scy5pZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYWMrY29yZUB6aW5mYW5kZWwudG9vbHMuaWV0Zi5vcmc8L2E+
Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5
bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct
bGVmdDoxZXgiPiMzOTQ6IFBpbmcvcG9uZzxicj4NCjxicj4NCjxicj4NCkNvbW1lbnQgKGJ5IDxh
IGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMuVHNjaG9mZW5p
Z0BnbXgubmV0PC9hPik6PGJyPg0KPGJyPg0KwqBIZXJlIGlzIHRoZSBzdG9yeSBmb3IgYWRkaW5n
IGtlZXAtYWxpdmUgZnVuY3Rpb25hbGl0eSB0byB0aGUgQ29BUCBvdmVyIFRDUDxicj4NCsKgZG9j
dW1lbnQuPGJyPg0KPGJyPg0KwqBBZnRlciByZWFjaGluZyBvdXQgdG8gZm9sa3MgbWVhc3VyaW5n
IFRDUCB1c2FnZSBJIHdhcyB0b2xkIHRoYXQgdGhlIHVzZSBvZjxicj4NCsKgVENQIGtlZXBhbGl2
ZSBtZXNzYWdlcyBpcyBvZnRlbiB1bnJlbGlhYmxlIHNpbmNlIG5ldHdvcmsgb3BlcmF0b3JzIGRl
cGxveTxicj4NCsKgbWlkZGxlYm94ZXMsIHdoaWNoIHN1cHByZXNzIHRoZXNlIG1lc3NhZ2VzLjxi
cj4NCjxicj4NCsKgRm9yIHRoaXMgcmVhc29uIHdlIGFyZSBzdWdnZXN0aW5nIHRvIGFkZCBhIHBp
bmcvcG9uZyBtZXNzYWdlIHRvIHRoZSBDb0FQPGJyPg0KwqBvdmVyIFRDUCBkb2N1bWVudC4gSGVy
ZSBpcyBob3cgdGhpcyBjb3VsZCBsb29rIGxpa2UuPGJyPg0KPGJyPg0KwqBGaXJzdCwgd2UgZGVm
aW5lIGEgbmV3IENvQVAgTWV0aG9kIENvZGVzIChmb3IgdGhlIHJlcXVlc3QpIGFuZCBDb0FQPGJy
Pg0KwqBSZXNwb25zZSBDb2RlcyAoZm9yIHRoZSByZXNwb25zZXMpLiBMZXQgdXMgZ2l2ZSB0aGVt
IG5ldyBudW1iZXJzLCBzdWNoIGFzPGJyPg0KwqA3LjAxIChmb3IgUElORykgYW5kIDcuMDIgKGZv
ciBQT05HKS48YnI+DQo8YnI+DQrCoEhlcmUgaXMgYW4gZXhhbXBsZSBtZXNzYWdlIGV4Y2hhbmdl
Ojxicj4NCsKge3t7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBD
bGllbnTCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZXJ2ZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4N
CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgJmx0Oy0tLSBUQ1Ag
LS0tJmd0O8KgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCB8IENvbm5lY3Rpb24gU2V0dXAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgTk9OwqAgwqAgwqAgwqAg
wqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg
R0VUIC90ZW1wZXJhdHVyZSB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgfMKgIMKgKFRva2VuIDB4NzQpwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0tLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQrCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IHzCoCDCoE5PTiBbMHgyM2JjXcKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIHzCoCDCoDIuMDUgQ29udGVudMKgIMKgfDxicj4NCsKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoChUb2tlbiAweDc0KcKgIMKgfDxi
cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCZx
dW90OzIyLjUgQyZxdW90O8KgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAg
wqAgLi4uLi4uwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIHzCoCDCoHRpbWUgcGFzc2VzwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCAuLi4uLi7CoCDCoCDCoCB8PGJyPg0K
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCB8Ny4wMyBQaW5nwqAgwqAgwqAgwqAgwqB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgfChUb2tlbiAweDdmKcKgIMKgIMKgIHw8YnI+DQrCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7
fDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgfDcuMDIgUG9uZ8KgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwoVG9rZW4gMHg3ZinCoCDCoCDCoCB8PGJyPg0K
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCZsdDstLS0tLS0tLS0t
LS0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIHzCoCAmbHQ7LS0tIFRDUCAtLS0mZ3Q7wqAgwqB8PGJyPg0KwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIENvbm4uIFRlYWRvd27C
oCDCoHw8YnI+DQrCoH19fTxicj4NCjxicj4NCsKgVGhlIFBJTkcgcGFja2V0IHdvdWxkIGxvb2sg
YXMgZm9sbG93czo8YnI+DQo8YnI+DQrCoHt7ezxicj4NCsKgIMKgIMKgMMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgMcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgMjxicj4NCsKgIMKg
IMKgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDM8YnI+DQrC
oCDCoCArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPGJy
Pg0KwqAgwqAgfMKgIMKgIMKgIDB4MDHCoCDCoCDCoHzCoCDCoCDCoCAweGUxwqAgwqAgwqB8wqAg
wqAgwqAgMHg3ZsKgIMKgIMKgfDxicj4NCsKgIMKgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+DQo8YnI+DQrCoCDCoCDCoExlbsKgIMKgPcKgIMKg
IDAgLS0tLS0tJmd0O8KgIDB4MDE8YnI+DQrCoCDCoCDCoFRLTMKgIMKgPcKgIMKgIDEgX19fLzxi
cj4NCsKgIMKgIMKgQ29kZcKgID3CoCA3LjAxwqAgwqAgwqAtLSZndDsgMHhlMTxicj4NCsKgIMKg
IMKgVG9rZW4gPcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgMHg3Zjxicj4NCjxicj4NCsKgIMKgIMKg
IMKgIMKgIMKgIEZpZ3VyZTogUElORyBFbmNvZGluZyBFeGFtcGxlLjxicj4NCsKgfX19PGJyPg0K
PGJyPg0KwqBUaGUgUE9ORyBwYWNrZXQgaGFzIHRoZSBmb2xsb3dpbmcgc3RydWN0dXJlOjxicj4N
Cjxicj4NCsKge3t7PGJyPg0KwqAgwqAgwqAwwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAx
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAyPGJyPg0KwqAgwqAgwqAwIDEgMiAzIDQgNSA2
IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMzxicj4NCsKgIMKgICstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8YnI+DQrCoCDCoCB8wqAgwqAg
wqAgMHgwMcKgIMKgIMKgfMKgIMKgIMKgIDB4ZTLCoCDCoCDCoHzCoCDCoCDCoCAweDdmwqAgwqAg
wqB8PGJyPg0KwqAgwqAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKzxicj4NCjxicj4NCsKgIMKgIMKgTGVuwqAgwqA9wqAgwqAgMCAtLS0tLS0mZ3Q7wqAg
MHgwMTxicj4NCsKgIMKgIMKgVEtMwqAgwqA9wqAgwqAgMSBfX18vPGJyPg0KwqAgwqAgwqBDb2Rl
wqAgPcKgIDcuMDLCoCDCoCDCoC0tJmd0OyAweGUyPGJyPg0KwqAgwqAgwqBUb2tlbiA9wqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAweDdmPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgRmlndXJl
OiBQT05HIEVuY29kaW5nIEV4YW1wbGUuPGJyPg0KPHNwYW4gY2xhc3M9IiI+wqB9fX08YnI+DQo8
YnI+DQotLTxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCsKgUmVwb3J0ZXI6wqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqBPd25lcjrCoCBkcmFmdC1pZXRmLWNvcmUtY29hcC10
Y3AtPGJyPg0KwqAgPGEgaHJlZj0ibWFpbHRvOmhhcnRrZUB0emkub3JnIj5oYXJ0a2VAdHppLm9y
ZzwvYT7CoCDCoCDCoCDCoCDCoHzCoCA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNA
aWV0Zi5vcmc8L2E+PGJyPg0KwqAgwqAgwqBUeXBlOsKgIHByb3RvY29swqAgwqAgwqB8wqAgwqAg
wqAgU3RhdHVzOsKgIG5ldzxicj4NCsKgIGVuaGFuY2VtZW50wqAgwqAgwqAgwqAgwqAgwqAgfMKg
IMKgTWlsZXN0b25lOjxicj4NCsKgUHJpb3JpdHk6wqAgbWlub3LCoCDCoCDCoCDCoCB8wqAgwqAg
wqBWZXJzaW9uOjxicj4NCjwvc3Bhbj5Db21wb25lbnQ6wqAgY29hcC10Y3AtwqAgwqAgfMKgIFJl
c29sdXRpb246PGJyPg0KPHNwYW4gY2xhc3M9IiI+wqAgdGxzwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgfDxicj4NCsKgU2V2ZXJpdHk6wqAgQWN0aXZlIFdHwqAgwqAgfDxicj4NCsKgIERv
Y3VtZW50wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KPC9zcGFuPsKgS2V5d29yZHM6wqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqB8PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K
VGlja2V0IFVSTDogJmx0OzxhIGhyZWY9Imh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9j
b3JlL3RyYWMvdGlja2V0LzM5NCNjb21tZW50OjEiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9jb3JlL3RyYWMvdGlja2V0LzM5
NCNjb21tZW50OjE8L2E+Jmd0Ozxicj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+PGRpdiBjbGFzcz0i
aDUiPmNvcmUgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvY29yZS8iIHJlbD0i
bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvY29yZS88
L2E+Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y29y
ZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48YnI+
DQo8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K
--089e0122914a280e640531635557--


From nobody Tue Apr 26 06:39:38 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD00612D152; Tue, 26 Apr 2016 06:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 NFF7upcQW8M1; Tue, 26 Apr 2016 06:39:30 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 BCE5012D130; Tue, 26 Apr 2016 06:39:30 -0700 (PDT)
Received: from localhost ([::1]:54818 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1av3D8-0008Vz-4d; Tue, 26 Apr 2016 06:39:30 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Tue, 26 Apr 2016 13:39:30 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/388#comment:1
Message-ID: <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org>
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org>
X-Trac-Ticket-ID: 388
In-Reply-To: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160426133930.BCE5012D130@ietfa.amsl.com>
Resent-Date: Tue, 26 Apr 2016 06:39:30 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:39:37 -0000

#388: Multiple versions over the same connection


Comment (by Hannes.Tschofenig@gmx.net):

 The latest version of the CoAP over TCP document (version -02) does not
 contain a version field anymore. This does, however, raise the question
 how the client indicates what CoAP version to use. There are the following
 4 possible options:

 Option #1) Add version field back to the CoAP header
 Option #2) TLS/DTLS-style version exchange
 Option #3) Client indicates version + Server accepts / rejects
 Option #4) Client indicates version + Server accepts / rejects but
 provides additional info about what it supports in an error message

 My (weak) preference is for option #4. The figure below shows an example:

 {{{
                      Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.02 ClientHello  |
                            | (version = x)    |
                            +----------------->|
                            |                  |
                            |7.03 ServerHello  |
                            |<-----------------+
                            |                  |

                  Figure: Successful Version Negotiation
 }}}

 {{{
                         Client              Server
                            |                  |
                            | <--- TCP --->    |
                            | Connection Setup |
                            |                  |
                            |7.02 ClientHello  |
                            | (version = y)    |
                            +----------------->|
                            |                  |
                            |8.01 Alert        |
                            | (Incompatible    |
                            |  Version)        |
                            | (+version=x)     |
                            |<-----------------+
                            |                  |

                  Figure: Failed Version Negotiation
 }}}

 A new option conveys the version information.

 This message also shows the new error response message.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  protocol     |      Status:  new
  defect                 |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Tue Apr 26 06:41:04 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601AD12D130 for ; Tue, 26 Apr 2016 06:41:04 -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] 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 fAeTx63alT_c for ; Tue, 26 Apr 2016 06:41:02 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD2412D1A5 for ; Tue, 26 Apr 2016 06:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u3QDerhX006626 for ; Tue, 26 Apr 2016 15:40:53 +0200 (CEST)
Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3qvPPK2SGSzDNnC for ; Tue, 26 Apr 2016 15:40:53 +0200 (CEST)
Received: by mail-wm0-f42.google.com with SMTP id v188so129442183wme.1 for ; Tue, 26 Apr 2016 06:40:53 -0700 (PDT)
X-Gm-Message-State: AOPr4FVxcFhleeObiAdmiAe0aeaEt3GN4s51ZhXl3+nWG6qcT5AqToCPDrjeSSzInjhk6AJyYJg6irsDFzYkOw==
X-Received: by 10.194.103.98 with SMTP id fv2mr3467792wjb.23.1461678048821; Tue, 26 Apr 2016 06:40:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.45.166 with HTTP; Tue, 26 Apr 2016 06:40:09 -0700 (PDT)
In-Reply-To: 
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org> 
From: Klaus Hartke 
Date: Tue, 26 Apr 2016 15:40:09 +0200
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Julien Vermillard 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:41:04 -0000

Julien Vermillard wrote:
> Why not simply using CoAP reset messages as ping ?
>
> https://tools.ietf.org/html/rfc7252
>
>  Provoking a Reset
>       message (e.g., by sending an Empty Confirmable message) is also
>       useful as an inexpensive check of the liveness of an endpoint
>       ("CoAP ping").

CoAP over TCP/TLS/WebSockets does not have Reset messages. But it is
possible to use an empty message (0.00 code) for pings, which would be
in line with CoAP over UDP/DTLS. Do we need pongs?

Klaus


From nobody Tue Apr 26 06:54:25 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283F212D1B2 for ; Tue, 26 Apr 2016 06:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT7eUi-PFcIt for ; Tue, 26 Apr 2016 06:54:21 -0700 (PDT)
Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id 56C7012D163 for ; Tue, 26 Apr 2016 06:54:21 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 3B3DE536FBB; Tue, 26 Apr 2016 15:52:29 +0200 (CEST)
X-Originating-IP: 134.102.116.11
Received: from nar-3.local (unknown [134.102.116.11]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 4BA2CA80ED; Tue, 26 Apr 2016 15:52:28 +0200 (CEST)
Message-ID: <571F729A.1060507@tzi.org>
Date: Tue, 26 Apr 2016 15:52:26 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Klaus Hartke 
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>  
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:54:23 -0000

Klaus Hartke wrote:
> CoAP over TCP/TLS/WebSockets does not have Reset messages. But it is
> possible to use an empty message (0.00 code) for pings, which would be
> in line with CoAP over UDP/DTLS. Do we need pongs?

Now that would be "overloading"...

(But yes, we could specify that an empty message has no effect in a
CoAP-over-reliable connection.)

One argument for pongs was that they can provide a way to get assurance
from an application that it actually has processed notifications.
Of course, that would be additional semantics beyond the simple
ping/pong, so it would most naturally be an option in a signaling message.

Grüße, Carsten


From nobody Tue Apr 26 06:57:54 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5057C12D1B2; Tue, 26 Apr 2016 06:57:53 -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] 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 vFPGfgb9jexb; Tue, 26 Apr 2016 06:57:52 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E030712B065; Tue, 26 Apr 2016 06:57:51 -0700 (PDT)
Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id A2059C5A4E; Tue, 26 Apr 2016 15:57:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id CpJsGgTsPbdA; Tue, 26 Apr 2016 15:57:49 +0200 (CEST)
X-Originating-IP: 134.102.116.11
Received: from nar-3.local (unknown [134.102.116.11]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 56B0BC5A69; Tue, 26 Apr 2016 15:57:47 +0200 (CEST)
Message-ID: <571F73DA.7050508@tzi.org>
Date: Tue, 26 Apr 2016 15:57:46 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: trac+core@zinfandel.tools.ietf.org
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org>
In-Reply-To: <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 13:57:53 -0000

With TLS, we could do the version indication using ALPN.
(This would possibly be an argument for deciding #387 as "always".)

For TCP, we could provide a signaling message with a critical option.
Or we could make CoAP version 1 the default and add the signaling
message only when we need it.  That would be my preference.

Grüße, Carsten


From nobody Tue Apr 26 11:16:40 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4A12D567; Tue, 26 Apr 2016 11:16:39 -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] 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 JXt4P_ZcViqr; Tue, 26 Apr 2016 11:16:38 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C51712D0DA; Tue, 26 Apr 2016 11:16:38 -0700 (PDT)
Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A094A2CA1D; Tue, 26 Apr 2016 11:16:37 -0700 (PDT)
From: "Jim Schaad" 
To: 
Date: Tue, 26 Apr 2016 11:16:37 -0700
Message-ID: <069a01d19fe7$c5f1e080$51d5a180$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdGf4rAvCqw3akY7QXOaQ6AVk7FT8A==
Content-Language: en-us
Archived-At: 
Cc: core@ietf.org
Subject: [core] comments on draft-hartke-core-e2e-security-reqs
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Apr 2016 18:16:39 -0000

After the meeting I tried to do a front to back reading of this document
several times.  I regret to note that I only succeeded once (after about 4
glasses of wine), but will note that I was reading this on a Kindle and
therefore it suffered both from a smaller screen and some formatting errors.

I would like to suggest some major document overhauls that I think would
both improve the ability to read the document and might (but probably will
not) address some of the concerns that Hannes raised at the F2F meeting.

The document is very repetitive.  This makes the document harder to read as
one get confused and bored by dealing with the same statements over and over
again.  To deal with this, I would suggest that things be built on rather
than repeated. This means that one can start with a generic proxy in the
first section and deal with the issues of that case and then the rest of the
time one can just say - those things plus the following without repetition. 

I don't like the scenario based structure of the document.  One of the
problems that I have is that the list of scenarios is going to be endless
and difficult to think about in an exhaustive manner.  One starts with the
questions of what happens when you have a situation of dealing with scenario
#1 and then #2 and then what happens when you compose #1 and #2 (or #2 and
#1).  I think that it would be better to focus on the different types of
proxies that can be identified and then go on from there.  This makes it
easier to think about what needs to be placed in a new document that defines
a new proxy type as well.

For each different proxy type I would look at covering the following:
** Generic Description of what the proxy type does
** What it means for the proxy to be 1) untrusted, 2) semi-trusted and 3)
fully trusted.  Note that not all of these are applicable to any given proxy
type.  (For example, if one looks at a NAT proxy then only untrusted makes
sense.)
** An example scenario for each of the different trust levels for the proxy.
This is where there is the greatest problem in trying to come up with real
world rather than academic examples might be the hardest thing to do.
** Look at the threats and requirements for each trust level building on a
base.  I.e. start the list with a single requirement of "Incorporate the
following requirements by reference A1, A2, A3, A4".

Start the document with some type of generic proxy.  I would suggest a NAT
proxy as this is something that is simple and easy to talk about as it does
not do any changes to the CoAP message and thus is trivial to understand.

Include a description of the above security levels and what they imply in
terms of key sharing and trust sharing.

Include a description of how one should think about composing proxies
together into a single unit.  Depending on how one does the analysis, I
think that this can be treated as dealing with the capabilities of each
proxy separately if they are combined into a single unit and can easily be
treated as separate things when they are not treated as a single unit.  Part
of the question is what one wants to say about proxies that collude together
as oppose to be the same proxy.

(day #2)

I can understand there might be a desire to talk about conversations between
entities.  However, these should focus on the conversation and ignore the
middle entities.  That is there are going to be generic issues that deal
with the following situations:

1) Send message from A to B.  
2) Multicast message from A to Group B
3) Round trip from A to B.
4) Multicast message from A to Group B w/ single cast reply
5) Multicast message from A to Group B w/ multi-cast reply to group B
(assuming that A is in Group B)

Jim



From nobody Tue Apr 26 21:26:11 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278D812B05F; Tue, 26 Apr 2016 21:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4V4v06IMAGR; Tue, 26 Apr 2016 21:26:08 -0700 (PDT)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62F5812B049; Tue, 26 Apr 2016 21:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=mhc3nzownH3DGRqpw/zyAztFxP8sZCZUGWG1DRRBHKI=; b=YsWCF2muLK1XVRPLOl3c1ZXHf8 uF2hAPdG+NKBcdgDtBOp+nPgZYHUZCPH4MXY4CrZfLlULl3TR/+vt4ZUQfyGWC58zTyb04H1MPkTM saCrLrrCRGVxxsBT1iJUDgIRf/i+6cvmLNo8mZYzTu2NVtY3n+pU8xHZhc2kHn9TcCN3pcIhvlz4R Axo+ToCLB2H/iPPiqtQDcfWVZda3alU+DS4jKWmrgcQVv3FWjnSU3HLM2rsgnWVR0dWH7UIqNUbkQ lJdqvpmAT6WYJLiHoGj/Z12PySaD3FAmBjJgw6dzr21tCRMfRpI5bb71P8QTqMIP/Vz+SfDIpIXWf iO6D2u8A==;
Received: from ppp118-209-116-64.lns20.mel4.internode.on.net ([118.209.116.64]:51826 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1avH36-001NdT-KA; Wed, 27 Apr 2016 14:26:04 +1000
To: trac+core@zinfandel.tools.ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org>
From: Christian Groves 
Message-ID: <182ce2c0-a70d-a79a-b047-e801fb0ecf4e@nteczone.com>
Date: Wed, 27 Apr 2016 14:26:02 +1000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 04:26:10 -0000

Is there any assumption that new CoAP versions need to be backward 
compatible? I didn't see anything mentioned in RFC7252.

Christian

On 26/04/2016 11:39 PM, core issue tracker wrote:
> #388: Multiple versions over the same connection
>
>
> Comment (by Hannes.Tschofenig@gmx.net):
>
>   The latest version of the CoAP over TCP document (version -02) does not
>   contain a version field anymore. This does, however, raise the question
>   how the client indicates what CoAP version to use. There are the following
>   4 possible options:
>
>   Option #1) Add version field back to the CoAP header
>   Option #2) TLS/DTLS-style version exchange
>   Option #3) Client indicates version + Server accepts / rejects
>   Option #4) Client indicates version + Server accepts / rejects but
>   provides additional info about what it supports in an error message
>
>   My (weak) preference is for option #4. The figure below shows an example:
>
>   {{{
>                        Client              Server
>                              |                  |
>                              | <--- TCP --->    |
>                              | Connection Setup |
>                              |                  |
>                              |7.02 ClientHello  |
>                              | (version = x)    |
>                              +----------------->|
>                              |                  |
>                              |7.03 ServerHello  |
>                              |<-----------------+
>                              |                  |
>
>                    Figure: Successful Version Negotiation
>   }}}
>
>   {{{
>                           Client              Server
>                              |                  |
>                              | <--- TCP --->    |
>                              | Connection Setup |
>                              |                  |
>                              |7.02 ClientHello  |
>                              | (version = y)    |
>                              +----------------->|
>                              |                  |
>                              |8.01 Alert        |
>                              | (Incompatible    |
>                              |  Version)        |
>                              | (+version=x)     |
>                              |<-----------------+
>                              |                  |
>
>                    Figure: Failed Version Negotiation
>   }}}
>
>   A new option conveys the version information.
>
>   This message also shows the new error response message.
>


From nobody Tue Apr 26 23:02:06 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA712D5E2; Tue, 26 Apr 2016 23:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Be0HuxLl40Hc; Tue, 26 Apr 2016 23:02:03 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7767512D5E0; Tue, 26 Apr 2016 23:02:03 -0700 (PDT)
Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1CB1C1720B1; Wed, 27 Apr 2016 08:02:02 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id v83yy6JqYWhE; Wed, 27 Apr 2016 08:01:59 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A01161720A9; Wed, 27 Apr 2016 08:01:58 +0200 (CEST)
Message-ID: <572055D4.2030806@tzi.org>
Date: Wed, 27 Apr 2016 08:01:56 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Christian Groves 
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org> <182ce2c0-a70d-a79a-b047-e801fb0ecf4e@nteczone.com>
In-Reply-To: <182ce2c0-a70d-a79a-b047-e801fb0ecf4e@nteczone.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 06:02:05 -0000

Hi Christian,

> Is there any assumption that new CoAP versions need to be backward
> compatible? I didn't see anything mentioned in RFC7252.

UDP CoAP packets have a "version number" because there were two bits
free in the header and we wanted to have a specific bit pattern in there
so CoAP packets multiplex nicely with DTLS and STUN packets on the same
port.

Nobody had or has any idea what a future version of CoAP would look
like; no need for one has come up*).  A different version number would
only be used to ensure that current CoAP implementations never process
messages in a future new format; CoAP's protocol evolution method is to
use options.

In a reliable stream (TCP/TLS/Websockets), there is no need to indicate
a protocol version per-message; if version negotiation is ever required,
this can be done at the start of the stream.

Grüße, Carsten

PS.: I'm not sure people have tried using different HTTP versions (1.0
vs. 1.1) within the same TCP connection; not that HTTP versions ever
meant that much...   (See the note in Section 3.5 of RFC 7540 for the
HTTP/2 view on that.)

*)  OK, maybe we want to have a longer message ID in a future high-rate
variant of UDP CoAP.  No message-IDs are needed in TCP CoAP...


From nobody Wed Apr 27 00:07:54 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823A412D5CB for ; Wed, 27 Apr 2016 00:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level: 
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 Eb1GvPxYJ9HI for ; Wed, 27 Apr 2016 00:07:50 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7786312B046 for ; Wed, 27 Apr 2016 00:07:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A24C5902; Wed, 27 Apr 2016 09:07:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yLqjO8TWzilq; Wed, 27 Apr 2016 09:07:37 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Apr 2016 09:07:47 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC61E2004A; Wed, 27 Apr 2016 09:07:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RUIK9H_OcGNE; Wed, 27 Apr 2016 09:07:46 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF79420046; Wed, 27 Apr 2016 09:07:45 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EE5F13AB7BAC; Wed, 27 Apr 2016 09:07:44 +0200 (CEST)
Date: Wed, 27 Apr 2016 09:07:44 +0200
From: Juergen Schoenwaelder 
To: Hannes Tschofenig 
Message-ID: <20160427070744.GA21138@elstar.local>
Mail-Followup-To: Hannes Tschofenig , Carsten Bormann , "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org> <571DEF4A.50506@gmx.net> <20160425103338.GA17158@elstar.local> <571DF986.6000200@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <571DF986.6000200@gmx.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "core@ietf.org WG" 
Subject: Re: [core] Using Yang to describe LWM2M ... was Re: ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 07:07:53 -0000

On Mon, Apr 25, 2016 at 01:03:34PM +0200, Hannes Tschofenig wrote:
> Hi Juergen,
> 
> On 04/25/2016 12:33 PM, Juergen Schoenwaelder wrote:
> > Hannes,
> > 
> > whether this YANG fragment makes sense or not I simply do not know
> > without knowing LWM2M and since there are no open specs there is
> > little help you can expect. I have no clue about the interaction model
> > of OMA LWM2M nor do I know what LWM2M_Device is etc.
> 
> The specs are publically available for download at no cost.
> 
> Here is the link:
> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0
> 
> You want to look at the 'Technical Specification'.

They are not open, I have to accept certain legal terms to get
access. In particular:

  use all or any part of a Document as part of a specification or
  standard not emanating from the Licensor without the prior written
  consent of the Licensor

I might already need a written consent if I post an example here since
everything posted to an IETF list may be considered a contribution.
 
> The registry for the objects are also public and available in a nicely
> written page (similar to what IANA provides for the IETF):
> http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry
>

Looking at examples to infer what the semantics of the schema are is
not what I am going to spend my time on.

> There is no permission that needs to be obtained IMHO, if I understand
> the OMA copyright policy correctly.

See above.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Apr 27 04:22:02 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF50612D7B2; Wed, 27 Apr 2016 04:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxtuzLgj9tEh; Wed, 27 Apr 2016 04:21:59 -0700 (PDT)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8488612D7AE; Wed, 27 Apr 2016 04:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=UBJn/VQceWTsaAg887rM/233xvHX/LZUD28ep4vEfHg=; b=mKoJCTEpjmrgmk+NAmKmBLmfTx eW9XlKmeuLKEwbvXGhzjexr03PUaSm2jWms6XNzylWTpBHA0aHRPXRcoXkGURSaJyDz3YA6hQRotd jHvMxWjO7BLr2xbkyEJWH+62IcUxMkkbDqd+k9U5hWiYq0/r47ayN6i27uGW8ulN677OMjH2cMFWN pQLlK/WjrP+A0BKd5rb6ifbRbkt9R6CPItfuhGihJDvqgFtknWC5QOdMqdYqsAMyy4ZoykSWPHpF7 OQHVgKMBjjj5Q6pPWfiyaQscg0zuBEgC87R0sfPYOO68ZdEO/zwQ1nwYStpZfHtG3E4X9x7oeXJpa WRaly5QA==;
Received: from ppp118-209-116-64.lns20.mel4.internode.on.net ([118.209.116.64]:63125 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1avNXX-002Lib-HL; Wed, 27 Apr 2016 21:21:55 +1000
To: Carsten Bormann 
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org> <182ce2c0-a70d-a79a-b047-e801fb0ecf4e@nteczone.com> <572055D4.2030806@tzi.org>
From: Christian Groves 
Message-ID: <38f0a660-5851-d816-fa7f-ec04c6e1e596@nteczone.com>
Date: Wed, 27 Apr 2016 21:21:52 +1000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <572055D4.2030806@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 11:22:01 -0000

Hello Carsten,

Thanks for the background. I agree version negotiation for a reliable 
would be done at the start at the start of the stream. I was thinking 
that having backward compatible versioning might simplify negotiation 
but it seems one can't make that assumption.

Regards, Christian

On 27/04/2016 4:01 PM, Carsten Bormann wrote:
> Hi Christian,
>
>> Is there any assumption that new CoAP versions need to be backward
>> compatible? I didn't see anything mentioned in RFC7252.
> UDP CoAP packets have a "version number" because there were two bits
> free in the header and we wanted to have a specific bit pattern in there
> so CoAP packets multiplex nicely with DTLS and STUN packets on the same
> port.
>
> Nobody had or has any idea what a future version of CoAP would look
> like; no need for one has come up*).  A different version number would
> only be used to ensure that current CoAP implementations never process
> messages in a future new format; CoAP's protocol evolution method is to
> use options.
>
> In a reliable stream (TCP/TLS/Websockets), there is no need to indicate
> a protocol version per-message; if version negotiation is ever required,
> this can be done at the start of the stream.
>
> Grüße, Carsten
>
> PS.: I'm not sure people have tried using different HTTP versions (1.0
> vs. 1.1) within the same TCP connection; not that HTTP versions ever
> meant that much...   (See the note in Section 3.5 of RFC 7540 for the
> HTTP/2 view on that.)
>
> *)  OK, maybe we want to have a longer message ID in a future high-rate
> variant of UDP CoAP.  No message-IDs are needed in TCP CoAP...
>


From nobody Wed Apr 27 06:57:57 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7512D1B6 for ; Wed, 27 Apr 2016 06:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 oc58sulgyxSe for ; Wed, 27 Apr 2016 06:57:55 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 7528312D1A9 for ; Wed, 27 Apr 2016 06:57:54 -0700 (PDT)
Received: from localhost ([::1]:44023 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avPyQ-0002M8-4A; Wed, 27 Apr 2016 06:57:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 27 Apr 2016 13:57:50 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/402
Message-ID: <052.afe507cbdb0a58173eb88ad02c4f8b5f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 402
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-links-json@ietf.org
Resent-Message-Id: <20160427135754.7528312D1A9@ietfa.amsl.com>
Resent-Date: Wed, 27 Apr 2016 06:57:54 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #402 (links-json): A reference implementation for links-json would be useful.
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 13:57:56 -0000

#402: A reference implementation for links-json would be useful.

 links-json has been promising for some that a reference implementation
 would be added.
 One such reference implementation probably needs some polishing before it
 can be included.
 Is there enough value in a reference implementation to wait for it to be
 included?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-links-
  cabo@tzi.org           |  json@tools.ietf.org
     Type:  editorial    |     Status:  new
 Priority:  minor        |  Milestone:
Component:  links-json   |    Version:  links-json-05
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Wed Apr 27 07:04:11 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FFD12D7F7 for ; Wed, 27 Apr 2016 07:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 2XNMHVsGpdEw for ; Wed, 27 Apr 2016 07:04:09 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 300A112D1D2 for ; Wed, 27 Apr 2016 07:04:09 -0700 (PDT)
Received: from localhost ([::1]:44518 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avQ4W-0002Vf-Ul; Wed, 27 Apr 2016 07:04:08 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 27 Apr 2016 14:04:08 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/403
Message-ID: <052.3af9ec97625b82887b23f6f7cb3e7b42@trac.tools.ietf.org>
X-Trac-Ticket-ID: 403
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-links-json@ietf.org
Resent-Message-Id: <20160427140409.300A112D1D2@ietfa.amsl.com>
Resent-Date: Wed, 27 Apr 2016 07:04:09 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #403 (links-json): Should the RFC 7390 part of links-json be split off?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 14:04:10 -0000

#403: Should the RFC 7390 part of links-json be split off?

 At IETF95, Hannes commented that the RFC 7390 parts of links-json appear
 to be less mature than the RFC 6690 parts.  Should they be split off into
 a separate document?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-links-
  cabo@tzi.org           |  json@tools.ietf.org
     Type:  other        |     Status:  new
  technical              |  Milestone:
 Priority:  major        |    Version:  links-json-05
Component:  links-json   |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Wed Apr 27 08:03:29 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A993012D83B for ; Wed, 27 Apr 2016 08:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 hzC6yNkKVKWQ for ; Wed, 27 Apr 2016 08:03:26 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C798E12D82D for ; Wed, 27 Apr 2016 08:03:20 -0700 (PDT)
Received: from localhost ([::1]:48934 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avQzo-0002by-Co; Wed, 27 Apr 2016 08:03:20 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 27 Apr 2016 15:03:20 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/404
Message-ID: <052.cb798e74d0275b4e793c5377c157ca6f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 404
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-links-json@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-links-json@ietf.org
Resent-Message-Id: <20160427150320.C798E12D82D@ietfa.amsl.com>
Resent-Date: Wed, 27 Apr 2016 08:03:20 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #404 (links-json): The group-format representations in CBOR use textual representations of IP addresses and port numbers
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 15:03:28 -0000

#404: The group-format representations in CBOR use textual representations of IP
addresses and port numbers

 The group-format representations in CBOR use textual representations of IP
 addresses and port numbers, where binary representations would be more
 natural in CBOR.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-links-
  cabo@tzi.org           |  json@tools.ietf.org
     Type:  protocol     |     Status:  new
  enhancement            |  Milestone:
 Priority:  minor        |    Version:  links-json-05
Component:  links-json   |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Wed Apr 27 08:59:59 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D991212D899 for ; Wed, 27 Apr 2016 08:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 oXlL00_pyGPs for ; Wed, 27 Apr 2016 08:59:56 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 6685E12D891 for ; Wed, 27 Apr 2016 08:59:56 -0700 (PDT)
Received: from localhost ([::1]:54113 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avRsW-0006Q9-E3; Wed, 27 Apr 2016 08:59:52 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-resource-directory@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 27 Apr 2016 15:59:52 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/405
Message-ID: <052.bbf1ea57631d92052fecf668bfbaa79f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 405
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-resource-directory@ietf.org
Resent-Message-Id: <20160427155956.6685E12D891@ietfa.amsl.com>
Resent-Date: Wed, 27 Apr 2016 08:59:56 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core] #405 (resource-directory): A link attribute cannot restrict the link-format syntax
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 15:59:58 -0000

#405: A link attribute cannot restrict the link-format syntax

 {{{
       link-extension    = ( "ins" "=" quoted-string ) ; Max 63 bytes
 }}}

 appears to restrict "ins" values to be represented as quoted strings.
 However, RFC 5988 and RFC 6690 define that a link-extension attribute can
 be represented without quoted strings, as long as it conforms to the
 `ptoken` production:

 {{{
   link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )
 }}}

 Fix:

 {{{
       link-extension    = ( "ins" "=" (ptoken | quoted-string) ) ; Max 63
 bytes
 }}}

 (Note that a similar consideration applies to "exp"; however, only the
 valueless case is allowed in resource-directory.)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-resource-
  cabo@tzi.org           |  directory@tools.ietf.org
     Type:  protocol     |     Status:  new
  defect                 |  Milestone:
 Priority:  minor        |    Version:
Component:  resource-    |   Keywords:
  directory              |
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Wed Apr 27 09:16:27 2016
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 5210412D514; Wed, 27 Apr 2016 09:16:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160427161626.25201.6580.idtracker@ietfa.amsl.com>
Date: Wed, 27 Apr 2016 09:16:26 -0700
Archived-At: 
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-links-json-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 16:16:26 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : Representing CoRE Formats in JSON and CBOR
        Authors         : Kepeng LI
                          Akbar Rahman
                          Carsten Bormann
	Filename        : draft-ietf-core-links-json-05.txt
	Pages           : 17
	Date            : 2016-04-27

Abstract:
   JavaScript Object Notation, JSON (RFC7159) is a text-based data
   format which is popular for Web based data exchange.  Concise Binary
   Object Representation, CBOR (RFC7049) is a binary data format which
   has been optimized for data exchange for the Internet of Things
   (IoT).  For many IoT scenarios, CBOR formats will be preferred since
   it can help decrease transmission payload sizes as well as
   implementation code sizes compared to other data formats.

   Web Linking (RFC5988) provides a way to represent links between Web
   resources as well as the relations expressed by them and attributes
   of such a link.  In constrained networks, a collection of Web links
   can be exchanged in the CoRE link format (RFC6690).  Outside of
   constrained environments, it may be useful to represent these
   collections of Web links in JSON, and similarly, inside constrained
   environments, in CBOR.  This specification defines a common format
   for this.

   Group Communication for the Constrained Application Protocol
   (RFC7390) defines a number of JSON formats for controlling
   communication between groups of nodes employing the Constrained
   Application Protocol (CoAP).  In a similar vein, this specification
   defines CBOR variants of these formats.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-links-json/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-links-json-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-05


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

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


From nobody Wed Apr 27 09:29:17 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E624212D89E for ; Wed, 27 Apr 2016 09:29: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] 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 CXSlq9_rUzdA for ; Wed, 27 Apr 2016 09:29:13 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D69E12D8A5 for ; Wed, 27 Apr 2016 09:29:09 -0700 (PDT)
Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 62A9CFB8C6; Wed, 27 Apr 2016 18:29:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ncIPmEG4wuXg; Wed, 27 Apr 2016 18:29:05 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9C487FB8A7; Wed, 27 Apr 2016 18:29:05 +0200 (CEST)
Message-ID: <5720E8CF.2000306@tzi.org>
Date: Wed, 27 Apr 2016 18:29:03 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: core@ietf.org
References: <20160427161626.25201.6580.idtracker@ietfa.amsl.com>
In-Reply-To: <20160427161626.25201.6580.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [core] I-D Action: draft-ietf-core-links-json-05.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 16:29:16 -0000

As you have seen, we have tried to trackerize the open issues on the
core-links-json document (#402..#404, see
https://tools.ietf.org/wg/core/trac/report/9).  A version of the
document that reflects the discussion except for the open issues is at:

Htmlized:       https://tools.ietf.org/html/draft-ietf-core-links-json-05
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-05

The authors hope that we can resolve the open issues and make a -06
based on that soon.

Grüße, Carsten


internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Constrained RESTful Environments of the IETF.
> 
>         Title           : Representing CoRE Formats in JSON and CBOR
>         Authors         : Kepeng LI
>                           Akbar Rahman
>                           Carsten Bormann
> 	Filename        : draft-ietf-core-links-json-05.txt
> 	Pages           : 17
> 	Date            : 2016-04-27
> 
> Abstract:
>    JavaScript Object Notation, JSON (RFC7159) is a text-based data
>    format which is popular for Web based data exchange.  Concise Binary
>    Object Representation, CBOR (RFC7049) is a binary data format which
>    has been optimized for data exchange for the Internet of Things
>    (IoT).  For many IoT scenarios, CBOR formats will be preferred since
>    it can help decrease transmission payload sizes as well as
>    implementation code sizes compared to other data formats.
> 
>    Web Linking (RFC5988) provides a way to represent links between Web
>    resources as well as the relations expressed by them and attributes
>    of such a link.  In constrained networks, a collection of Web links
>    can be exchanged in the CoRE link format (RFC6690).  Outside of
>    constrained environments, it may be useful to represent these
>    collections of Web links in JSON, and similarly, inside constrained
>    environments, in CBOR.  This specification defines a common format
>    for this.
> 
>    Group Communication for the Constrained Application Protocol
>    (RFC7390) defines a number of JSON formats for controlling
>    communication between groups of nodes employing the Constrained
>    Application Protocol (CoAP).  In a similar vein, this specification
>    defines CBOR variants of these formats.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-links-json/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-core-links-json-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-05
> 
> 
> 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
> 


From nobody Wed Apr 27 09:44:19 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEBD12D91A for ; Wed, 27 Apr 2016 09:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 yMR8etC2j5-h for ; Wed, 27 Apr 2016 09:44:15 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBFE12D919 for ; Wed, 27 Apr 2016 09:44:14 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMk99-1b3zXw1kcx-008XTj; Wed, 27 Apr 2016 18:44:11 +0200
To: Julien Vermillard , "core@ietf.org" 
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org> 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5720EC66.3010707@gmx.net>
Date: Wed, 27 Apr 2016 18:44:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VqoCdjB0MCDvWBquQ2ndJ687lt8oewGEU"
X-Provags-ID: V03:K0:m2JSbYNpIF9SDO8ubSsNJH9ZOhAGu5VWjKAEUFnI4TBS4e63w6d 2j88HpoeK53M4rZ5YxIvWrtogTfnfAiMqlx7iWgA7ByHej7xAsI9kVjbdXjBWho8EJFN61z MWXgTQtPjlO4EreqU0OFi3UyLCEn5nyrrI0y+IFrA/ojBNgd5bOK8Ya4U54rkUyGjEwFB7L gdcy44jb3Re0xh2fVJ8rA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XUkp+QDxzUg=:vs9EQIsKUwhgSxyEMQ0OnJ +qr2ceNSxTUicsPajPh0TxOSIj4W9EKiL8WxmgvnLxKIQc9NAngpuuCiD3JwzQ0CzzanospB3 qtOubLXfHEYB8KPbmK+7svW4l4m/zQOhjQrYPFegp0tVeNA8KuroXvMmXnqxSNLu8LeCPwGvR uQfK0H9X3XkYVDBa17MHdNgcr+qlDT12FWuOthrjdR9rrxTGMmpLugt61m3USOnwinjDS2oct QxXC85R5cT3oPdXS/VtZNSSPx1x4TCqdNFZzhZPebueA0HhYMQTUdO8CUzalAnxwlNC1aChcz 06XTQmRIjJoRVRP69TnGVfAOvaEP7mlx6QxyJAil8JNeNQZO5bF0euvt9UMBQCuQKfR0FGQWm ICRD5aUozQ8gMJSrkx42wwh6DxTuzVgSt6AwZ8SXm2/H4F1ZiM0TRz5qflJYl8YZj+0x/4UlV reJ/6L2uQ1ss6Sh8GgMedRTv+hRGhc7NOGlvdQsqtoJ+I4zU55TRAj0x7a2jse3C46ODgofd4 S6gQscKkTc4endfrMfP6QBZsJoQr7fhohsnb2fVyzF/TsBNc7SrP27yFqvSiFpvCSz+J2uoOv s1Xc+mFNCmFRldeYThyj2cfRi1QpGV+6IDkkl0Y3ZQhAEQL4Iznibd/rf/US0gxoh+4Ta17hR YVg4ddXLwUhhLmk+1TlYEaKJeAteJBtxKMEILiCKW8kGnRdAcdelWUvx9qSYKJiNWFiMmYRP5 y+7Y356VIINvt3LsOgxriRdgruE6uvcv9rwB79nVYTGbDhgveg5VuNJZLr8=
Archived-At: 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 16:44:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--VqoCdjB0MCDvWBquQ2ndJ687lt8oewGEU
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Julien,

Very good question.

The thought process behind introducing a new request/response message
pattern here was that we wanted to separate functionality that concerned
the shim header protocol from the actual CoAP protocol exchange. What
may confuse a little bit is that we are trying to re-use the CoAP
protocol encoding for the shim header protocol as well.

In the write-up we will obviously have to make sure that this difference
is clearly pointed out (somehow).

Ciao
Hannes


On 04/26/2016 03:32 PM, Julien Vermillard wrote:
> Why not simply using CoAP reset messages as ping ?
>=20
> https://tools.ietf.org/html/rfc7252
>=20
>  Provoking a Reset
>       message (e.g., by sending an Empty Confirmable message) is also
>       useful as an inexpensive check of the liveness of an endpoint
>       ("CoAP ping").
>=20
>=20
>=20
> --
> Julien Vermillard
>=20
> On Tue, Apr 26, 2016 at 2:47 PM, core issue tracker
>  > wrote:
>=20
>     #394: Ping/pong
>=20
>=20
>     Comment (by Hannes.Tschofenig@gmx.net
>     ):
>=20
>      Here is the story for adding keep-alive functionality to the CoAP
>     over TCP
>      document.
>=20
>      After reaching out to folks measuring TCP usage I was told that th=
e
>     use of
>      TCP keepalive messages is often unreliable since network operators=

>     deploy
>      middleboxes, which suppress these messages.
>=20
>      For this reason we are suggesting to add a ping/pong message to th=
e
>     CoAP
>      over TCP document. Here is how this could look like.
>=20
>      First, we define a new CoAP Method Codes (for the request) and CoA=
P
>      Response Codes (for the responses). Let us give them new numbers,
>     such as
>      7.01 (for PING) and 7.02 (for PONG).
>=20
>      Here is an example message exchange:
>      {{{
>                              Client              Server
>                                 |                  |
>                                 | <--- TCP --->    |
>                                 | Connection Setup |
>                                 |                  |
>                                 |   NON            |
>                                 | GET /temperature |
>                                 |   (Token 0x74)   |
>                                 +----------------->|
>                                 |                  |
>                                 |   NON [0x23bc]   |
>                                 |   2.05 Content   |
>                                 |   (Token 0x74)   |
>                                 |     "22.5 C"     |
>                                 |<-----------------+
>                                 |                  |
>                                 |      ......      |
>                                 |   time passes    |
>                                 |      ......      |
>                                 |                  |
>                                 |7.03 Ping         |
>                                 |(Token 0x7f)      |
>                                 +----------------->|
>                                 |                  |
>                                 |7.02 Pong         |
>                                 |(Token 0x7f)      |
>                                 |<-----------------+
>                                 |                  |
>                                 |  <--- TCP --->   |
>                                 |  Conn. Teadown   |
>      }}}
>=20
>      The PING packet would look as follows:
>=20
>      {{{
>          0                   1                   2
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |      0x01     |      0xe1     |      0x7f     |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>          Len   =3D    0 ------>  0x01
>          TKL   =3D    1 ___/
>          Code  =3D  7.01     --> 0xe1
>          Token =3D               0x7f
>=20
>                 Figure: PING Encoding Example.
>      }}}
>=20
>      The PONG packet has the following structure:
>=20
>      {{{
>          0                   1                   2
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |      0x01     |      0xe2     |      0x7f     |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>          Len   =3D    0 ------>  0x01
>          TKL   =3D    1 ___/
>          Code  =3D  7.02     --> 0xe2
>          Token =3D               0x7f
>=20
>                 Figure: PONG Encoding Example.
>      }}}
>=20
>     --
>     -------------------------+-----------------------------------------=
--------
>      Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
>       hartke@tzi.org          |  tls@ietf.org
>     
>          Type:  protocol     |      Status:  new
>       enhancement            |   Milestone:
>      Priority:  minor        |     Version:
>     Component:  coap-tcp-    |  Resolution:
>       tls                    |
>      Severity:  Active WG    |
>       Document               |
>      Keywords:               |
>     -------------------------+-----------------------------------------=
--------
>=20
>     Ticket URL:
>     
>     core 
>=20
>     _______________________________________________
>     core mailing list
>     core@ietf.org 
>     https://www.ietf.org/mailman/listinfo/core
>=20
>=20
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20


--VqoCdjB0MCDvWBquQ2ndJ687lt8oewGEU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXIOxmAAoJEGhJURNOOiAt5W8H/jm9S3uf+nJd1EBJFRc2QTq4
HT7mANnCkAxTwoZQUt77iO2BlfDH1l0CUiA+3AdPSIZak802ktxX87JVMz2OPA/z
x5FxwprC6OWZWCkdigbF2+QHvXbgTOZrAcSof/AiVzSXKTVFtFiMZZJbvPaGXsr8
2f/RDazkdhBigE7zf2Szm+hM8emvJXWly9DhBNBcwnqq9+wDZWwJpg6TxgLVjtFy
lzOcbLvGrhjO/vt5H/5LwvxpznQa7XLHPhOixbmBgwqCAG3xwJ9lDaoHYdOmf48N
YAlHS1mOng86cQxe2nUfJm9JGdvtAWYbd8YRnLYgzAqgA5pywBzxALvC66O4RgI=
=W71I
-----END PGP SIGNATURE-----

--VqoCdjB0MCDvWBquQ2ndJ687lt8oewGEU--


From nobody Wed Apr 27 09:45:45 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAEF12D92A for ; Wed, 27 Apr 2016 09:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 xJMQGBetToB7 for ; Wed, 27 Apr 2016 09:45:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC06312D921 for ; Wed, 27 Apr 2016 09:45:42 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MF5FT-1au3wU3RWd-00GGrs; Wed, 27 Apr 2016 18:45:34 +0200
To: Carsten Bormann , Klaus Hartke 
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>   <571F729A.1060507@tzi.org>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5720ECB8.9030607@gmx.net>
Date: Wed, 27 Apr 2016 18:45:44 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <571F729A.1060507@tzi.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HeGoDIwsgbi28LuKRTqmHKW7TlAUdoUna"
X-Provags-ID: V03:K0:1sQB7wMgPWaimcbnYYwsMhvPMoZ7cbdYKdXMhzoI0iHP+JJ4pOK YzTiFotP1Ec4gabkrWFOck/xwappBOUMPdK2TlRe8tFpiwO5h4m5KeZUNkcnWCAiX+BeK1N JuK8NLRFDWedcx3iOPxukknFy3Obk+2jMF9S3NaFKFrxToD0dUHFeOdeFBZgXifpCEugYzC lwgG+gnD0jcjon1YII/tQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:/XiRXPtZ8VU=:S4Ze1A07g86sVD0s9uG7b2 x6XDoNBDgAis9S65ETg2XnxrJxSoyAeJko5NL226HvljNvEMV+gXy1wRDX1/CQjNPlE+G06bo 1MMQFz5GsGMSmcJuiPotnD6ZIuiJ4E1T0tLzRJEvAWp9NyL0W4ExyxIJmUmJ4HMuwK/VQVn02 3lJ0rP0SWRwxnyb1+HZm1PE9YI/F+56ut6/v8eJp0TyT7SvJFkgvdXQn+qXYRx982B29xkUl/ vTlyX3zgBwB0V0vJi3EAbjyhxBodM0G2KX79zFWx3X6xVWBi9wo+NZ55ixvGJoUDb/8MFWsf2 OvY6x69cjbzAfBQfgqa3WUz2QlJQso0MZ7lVHDO6G2PmaGQtL0PrQ28AMywHmcpHbAl1+IAw6 bqtOmYz4k1ydCB6s56DDH0KPS4ig2RLOlxHzPT5H2tyJfJVmXwWGW7p7Gt6KAKkA4x+7EeFyc xdafeVj4e2VGJzzIW2g3SQqL+H5TH4iDwwGd00l55cPopgwBOXsM2wUC9KpaZM08bRvWwoo4h +Ik+Us4F2J0qzp/v550shEnd60k55QfEljfdT46slTwHMhuYOJDUuAcebXYX2qHoDOo6ulVPL 9e/hipe2gZaoxxPG0kzFtn37vHhou9gtlNj2kJILhIIqfeVmkZVZyiwl3iI6gRsBoe82ZBfVV 6pMaEy4qGTZvlVKcl9bT1adPuBsH0iHMlUh/67Ggw8LgF4Z6f6WqPSQNwe35sKMKZfrIPb0K3 t4KaM0FyVONg+OWuHlXeIYaPwuOwI8kHaIWOC/mzkHChsjG/2Hejbi9jA3g=
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 16:45:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HeGoDIwsgbi28LuKRTqmHKW7TlAUdoUna
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I prefer to have a ping/pong exchange to improve readability without a
lot of impact on anything. We clearly need a response message to the
request in order for this stuff to work.

Ciao
Hannes

On 04/26/2016 03:52 PM, Carsten Bormann wrote:
> Klaus Hartke wrote:
>> CoAP over TCP/TLS/WebSockets does not have Reset messages. But it is
>> possible to use an empty message (0.00 code) for pings, which would be=

>> in line with CoAP over UDP/DTLS. Do we need pongs?
>=20
> Now that would be "overloading"...
>=20
> (But yes, we could specify that an empty message has no effect in a
> CoAP-over-reliable connection.)
>=20
> One argument for pongs was that they can provide a way to get assurance=

> from an application that it actually has processed notifications.
> Of course, that would be additional semantics beyond the simple
> ping/pong, so it would most naturally be an option in a signaling messa=
ge.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>=20


--HeGoDIwsgbi28LuKRTqmHKW7TlAUdoUna
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXIOy4AAoJEGhJURNOOiAtRAMH/2DjPthERWuzhsEFtpbivrHe
ofRyyz3FfnMPRhin9XAD5ZON/zbJtrfZD3aDjPVyL2zioazxv0MnFghck0ghAIbV
B4y2FcxtDjq4d+Eton/xj685CJZQCl6jT3h3nUyyHcGuXOXwLAIYOFgQTzmnH8ET
4q3YXorbCYm9YwlRhjUISqOrBc/qVStfMMc9SirviBJq4mPEplBRvyi7+ZP7Mt/t
kgzEt3MQGV4PG9hgharJPQYwV9Y+G3DKAppPEXJVxUkukEfN82svtIb4P/kiM35x
Jz1tqiwumTeUwth274TCLp4fBuecMtUkGNuqHkY8I7YXswfb2sKOzbM8fP1I9J8=
=6XdG
-----END PGP SIGNATURE-----

--HeGoDIwsgbi28LuKRTqmHKW7TlAUdoUna--


From nobody Wed Apr 27 09:51:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C1612D954; Wed, 27 Apr 2016 09:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 UJzZTDaznCM6; Wed, 27 Apr 2016 09:51:19 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAA012D95A; Wed, 27 Apr 2016 09:51:18 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mhhr5-1bIEaO2EoF-00Mtfq; Wed, 27 Apr 2016 18:51:07 +0200
To: Carsten Bormann , trac+core@zinfandel.tools.ietf.org
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org> <571F73DA.7050508@tzi.org>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5720EE03.10205@gmx.net>
Date: Wed, 27 Apr 2016 18:51:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <571F73DA.7050508@tzi.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qb8XDx055DwATtaGJ9RcnqcbfswfxHpQS"
X-Provags-ID: V03:K0:p3gJKnfalWgimiHi+5BQ8xg7E6o34ESLHQ7cs7/qOXXMORZ1xjw bNfqs3VxGXSa2N6ak/GxfxUiNB1YbWQDCy1DMU2tA7RKaO5td4EbTMN67YUVYYYHiS1OpQk ekTvM7svleVG0lbcAQYBRj+CzoYRGEoxOxWhDTCsVzKFVB+231+yLDhKbAnExTfT4LFQ6Cn UIM/as00Ge/kkAvn9DZfw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:gNaSrfh9Z7M=:V0p5qAQnrrF3lrRFxPV3Mn gwge69wyWJJVobEQf2kyA8YQHedZdXSI8CfTW9LmnPwEZWhYIUAeLGW2GtqviXdtfdt9cwVJJ /fi62ClL0OmBe54UUB05tAGkesmOk7eK4OPGvWwZX8EEhSZZkDOw98DkgYJG4afMOWV0Bz8aH AQVued3nm6xUZcd9AIrdRhzsx80ezyIrjB3PsHy5k/+9Elz9Ggr4oOQ9Rg3NBqpzO3D9k5nGD DyW+tf77oaAuxlrV/LsbMCWrETOhLk+f5KUQEHfyU5/UXyVTYW2BvW0ybhfBuGUf4Y7GBnyYN pLtxYf7Oi06BBOxZlR7nHOmRytZtnU8EOprZ6Ilg7RdLBitQ03r4LgawgTXlSytewJXQvAhHi Kx+la1a9a55by46Rfpv3hjofGTbK7lHJNj2jm6eJl0bqZdWvlIs49zy1BDzuX76WCWRmvucwV rkPWHH3DXH1BRPWVuhn4Rm0EonvcNHpzuiVD1ocxi//G0twDy7L8bgVfNeIXiGKZCnmLXwm8D PiXuKFbKPOU1w1EpfkS9ocS7tH0a6tGWMPsh0qLngnaW4AJAe0zUC3bn3VFZtZp5PNkJpzCe8 9GPZiODjUf3JLUiU+K+hCvpBGMLlpZsPWOQIaVfy+ayeaMEa4dcS6V6rRrSdv2e3bFgFgi0pG VU5AHdy047ll0I9oo3MJRtCr0mvg6wz7Kt91MCUfQFVf0pJ14OB17+7WGnzTErZP9GLb2FNtd YBf4o0YU7/XZIwlNYa3UuKq5uNo2E0OygXglJipKZAq2375CUL32atIA/KI=
Archived-At: 
Cc: draft-ietf-core-coap-tcp-tls@ietf.org, core@ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 16:51:20 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Qb8XDx055DwATtaGJ9RcnqcbfswfxHpQS
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Making version 1 the default sounds reasonable to me.

There is, however, an important design consideration:

1) Should the version indication be added to each message, or
2) Should there be a version indication/negotiation at the beginning of
the handshake

The discussion I included in the issue tracker focused on option #2
since I assumed we do not want option #1.

Ciao
Hannes

On 04/26/2016 03:57 PM, Carsten Bormann wrote:
> With TLS, we could do the version indication using ALPN.
> (This would possibly be an argument for deciding #387 as "always".)
>=20
> For TCP, we could provide a signaling message with a critical option.
> Or we could make CoAP version 1 the default and add the signaling
> message only when we need it.  That would be my preference.
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20


--Qb8XDx055DwATtaGJ9RcnqcbfswfxHpQS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXIO4EAAoJEGhJURNOOiAt9W4H/RT+7BqAU+gT6SjpXjrFUT4y
wKWJxNzeZuILjTEh789qNHkUGoxvTaa/FJmcM5dLLCicNR6o2KiW2/L1V0g52tLT
V+UiEpOBxuNW0S0jLyLe2a8Vy0PotSn1nWxV65/MA8qVnyVrKdYEC1f5cRnC4Zpz
Guo2ePqQw22rkvv3u1InnW9ArhmM+DumRyFkz3strTk2kBttYxmny2Z+liiWmknQ
r7ttj/nDRvpWLZ4oYtErZQ/5sq5mVDyBLbXuvUpLTRGFoIxMdMVHstdyIT65Pna3
uF5pXqarixJvaq7W4KK2BNW5rj/CC2SsZTQ/Y7ip8atbLWGRPMC00y5aOa9K1Gc=
=XUm4
-----END PGP SIGNATURE-----

--Qb8XDx055DwATtaGJ9RcnqcbfswfxHpQS--


From nobody Wed Apr 27 11:24:13 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585D812DBA2; Wed, 27 Apr 2016 11:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 JbK2R1XJIPvx; Wed, 27 Apr 2016 11:24:09 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B48E12DB9F; Wed, 27 Apr 2016 11:24:09 -0700 (PDT)
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id F1868A80D9; Wed, 27 Apr 2016 20:24:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mfxNg-D52UUM; Wed, 27 Apr 2016 20:24:06 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B413AA80D7; Wed, 27 Apr 2016 20:24:04 +0200 (CEST)
Message-ID: <572103C3.6090802@tzi.org>
Date: Wed, 27 Apr 2016 20:24:03 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <054.aef06920484b3c4a22ed81045af09fce@trac.tools.ietf.org> <069.fd4e0c5e045b353a56cb0fb14a518d64@trac.tools.ietf.org> <571F73DA.7050508@tzi.org> <5720EE03.10205@gmx.net>
In-Reply-To: <5720EE03.10205@gmx.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org, trac+core@zinfandel.tools.ietf.org
Subject: Re: [core] #388 (coap-tcp-tls): Multiple versions over the same connection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 18:24:11 -0000

Hannes Tschofenig wrote:
> 1) Should the version indication be added to each message, or

No.

> 2) Should there be a version indication/negotiation at the beginning of
> the handshake

Yes.  (With the default being version 1.)

In any case, version numbers will be hop-by-hop.  (Cf. Section 2.1 of
RFC 2145 if you don't see what I'm trying to say here.)  It is hard to
see for me what would motivate an TCP endpoint to mix versions on one
connection.

Another question is whether we always want to have some initial
exchange, e.g.

1) to make cross-protocol attacks harder, or
2) just for its diagnostic value.

(I'm not a big fan of a passive opener ("TCP connection server") sending
unsolicited details right on connection open; this makes things too easy
for Shodan-like search engines.  If we don't do that, we essentially add
a roundtrip.  Probably not a big problem for CoAP-over-TCP connections
as these are likely to last longer than your typical HTTP connection.)

Grüße, Carsten


From nobody Wed Apr 27 11:39:38 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF412D557 for ; Wed, 27 Apr 2016 11:39:36 -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] 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 C_GqO1fZf5I1 for ; Wed, 27 Apr 2016 11:39:35 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E841512D53F for ; Wed, 27 Apr 2016 11:39:34 -0700 (PDT)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8D88BA80ED; Wed, 27 Apr 2016 20:39:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YgeIBBIPAwd8; Wed, 27 Apr 2016 20:39:31 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A92BEA80F0; Wed, 27 Apr 2016 20:39:30 +0200 (CEST)
Message-ID: <57210761.1080907@tzi.org>
Date: Wed, 27 Apr 2016 20:39:29 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <054.2c97c757dda98e52472c800c6ee42ad0@trac.tools.ietf.org> <069.b9f53805061e8e72bfdeccc1ae6055ae@trac.tools.ietf.org>   <571F729A.1060507@tzi.org> <5720ECB8.9030607@gmx.net>
In-Reply-To: <5720ECB8.9030607@gmx.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "core@ietf.org" , Klaus Hartke 
Subject: Re: [core] #394 (coap-tcp-tls): Ping/pong
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 18:39:36 -0000

In
https://mailarchive.ietf.org/arch/msg/core/W_fOB3ZrqCoUduVsovfZSHNcWMw I
wrote:

* Ping, pong: A ping message is responded to by a pong message with
  the same token.  No options are defined for Ping messages in this
  specification, but options might be defined later.  As with all
  signaling messages, the receiver of a ping or pong message MUST
  ignore elective options it does not understand.

Assumption here: echoing back a token is what we need (maybe there is a
point in echoing the payload, but maybe there also is a point in that
just being a diagnostic payload).  Simply counting pings and pongs will
also work for most applications.

So a ping might look like this (codepoints pulled out of thin air):

len tkl code token
0   4   7.11 0x47110815

The pong for that would be:

len tkl code token
0   4   7.12 0x47110815 (echoed back)

Here, the pinging application wanted to have four bytes echoed back (but
zero bytes would work as well, making this a two-plus-two-byte exchange).

Note that options could be added later (e.g., giving the whole exchange
checkpoint semantics); so the receiver of the ping should run the
message through the normal CoAP decoder and ignore elective options).

A simple keepalive message a la Julien would be:

len tkl code token
0   0   0.00 (empty)

(the only point of this "No-Op" is to refresh a NAT binding; there is no
application semantics.  So there also is no point in having options.)

Grüße, Carsten


From nobody Wed Apr 27 14:17:37 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2162512D0A6 for ; Wed, 27 Apr 2016 14:17:34 -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] 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 UBSYsOZZuaQG for ; Wed, 27 Apr 2016 14:17:32 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDD012DC31 for ; Wed, 27 Apr 2016 14:17:31 -0700 (PDT)
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D9B4C1720A9; Wed, 27 Apr 2016 23:17:29 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EW0Lzwbv0--p; Wed, 27 Apr 2016 23:17:28 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E4EB5172095; Wed, 27 Apr 2016 23:17:27 +0200 (CEST)
Message-ID: <57212C66.3010102@tzi.org>
Date: Wed, 27 Apr 2016 23:17:26 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "core@ietf.org WG" 
References: <570A4583.2030100@tzi.org>
In-Reply-To: <570A4583.2030100@tzi.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-veillette-core?= =?utf-8?q?-yang-cbor-mapping-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 21:17:35 -0000

The discussion that spawned from this adoption call is ongoing, but we
seem to have converged on (slightly rough*) consensus on adopting this
draft as a WG item.

Authors: please resubmit the current draft as
draft-ietf-core-yang-cbor-00.txt; we will start processing further
changes in the WG process.
(If you already know about technical issues, please use the WG tracker
at https://trac.tools.ietf.org/wg/core/trac/report/9 for now; editorial
issues might be tracked easier on github.)

Note that the yang-cbor draft is on github in the
https://github.com/core-wg/yang-cbor repository (which also contains
other drafts that may or may not converge into WG documents).  When the
renaming is complete, the current editor's copy of the WG draft will be
visible at:

http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html

*) the roughness was about the danger of the CoRE WG overextending
itself by taking on more work.  This will be actively watched by the
chairs, whose priority will continue to be on getting current work
finished.  However, there is significant new energy in the COMI/COOL
work, so the overall capacity of the WG will increase by starting to
work on this part of our charter.

Grüße, Carsten


Carsten Bormann wrote:
> In Buenos Aires, we discussed the adoption of
> draft-veillette-core-yang-cbor-mapping-00 but not enough people had read
> the document to go for an in-room consensus call.
> 
> This is a two-week call for adoption of
> draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE.
> Specifically, if you (1) support or (2) have an objection to this
> decision, please speak up on the mailing list by 2016-04-24.
> 
> Note that this work is explicitly covered by our charter, so discussions
> of which WG should work on this are off-topic.
> 
> As always, adoption of a document as a WG document is not a vote on
> whether we already have reached last-call state; the intention is to
> work on the WG document after adoption for a while to get it ready for
> last call.  If you want to combine your support/objection with technical
> comments, this is certainly welcome so we can accelerate that process.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 
> 


From nobody Wed Apr 27 14:45:04 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127AA12D1C8; Wed, 27 Apr 2016 14:44:57 -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] 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 u43GcYy7lqhv; Wed, 27 Apr 2016 14:44:55 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7F612B018; Wed, 27 Apr 2016 14:44:54 -0700 (PDT)
Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id AC46CA80CD; Wed, 27 Apr 2016 23:44:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eaM1_b2i4_MD; Wed, 27 Apr 2016 23:44:52 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C6773A80C2; Wed, 27 Apr 2016 23:44:50 +0200 (CEST)
Message-ID: <572132D1.4020608@tzi.org>
Date: Wed, 27 Apr 2016 23:44:49 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Suresh Krishnan 
References: <20160420035547.31549.85944.idtracker@ietfa.amsl.com>
In-Reply-To: <20160420035547.31549.85944.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org
Subject: Re: [core] Suresh Krishnan's No Objection on draft-ietf-core-block-19: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Apr 2016 21:44:57 -0000

Hi Suresh,

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Is there a specific reason that the 4.08 response code is overloaded for
> use for two different kinds of issues?
> 
> a) Mismatching Content-Format options in different blocks
> b)  not all previous blocks are available at the server at the time of
> processing the final block of an atomic operation

In the logic of this draft, these cases aren't so different:
If you start a new sequence of blocks with a different Content-Format in
the middle, the server is not going to have matching blocks available
for the previous block numbers.  So you get the same error code that you
get with starting a transfer in the middle from scratch.

> Section 7.1:
> 
> Have you thought about how this text can be made actionable, especially
> in the case of atomic PUT or POST requests without maintaining state? 

Mostly by "don't do that".
The problem is the same we have with reassembly buffers at the IP level.
You just make sure that you don't commit too many resources to them.

> If
> so, it would be good to elaborate here.
> 
> "Wherever possible, servers should therefore minimize the opportunities
> to create state for untrusted sources, e.g. by using stateless
> approaches."

i.e., best don't offer atomic transactions outside of authorized
connections.  (Or at least exercise tight control over the state
created, and discard early/often.)

Grüße, Carsten


From nobody Wed Apr 27 18:56:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAA012D51D for ; Wed, 27 Apr 2016 18:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 pb-RiGRw3a-F for ; Wed, 27 Apr 2016 18:56:18 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 6688B12D0AA for ; Wed, 27 Apr 2016 18:56:18 -0700 (PDT)
Received: from localhost ([::1]:48781 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avbBh-00009n-Mq; Wed, 27 Apr 2016 18:56:17 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-resource-directory@tools.ietf.org, akbar.rahman@interdigital.com
X-Trac-Project: core
Date: Thu, 28 Apr 2016 01:56:17 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/406
Message-ID: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 406
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-resource-directory@tools.ietf.org, akbar.rahman@interdigital.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-resource-directory@ietf.org
Resent-Message-Id: <20160428015618.6688B12D0AA@ietfa.amsl.com>
Resent-Date: Wed, 27 Apr 2016 18:56:18 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core]  #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 01:56:20 -0000

#406: Consider URI ranking, Privacy Model, etc. as part of RD

 In IETF-95, there was a discussion regarding various enhancements to the
 RD that should be considered as outlined in

 https://tools.ietf.org/html/draft-rahman-core-advanced-rd-features-02

 Examples of the enhancements included ranking of URI results from the RD
 lookup interface, and a clear privacy model for the RD lookup interface.


 The conclusion of the discussion in IETF-95 was summarized by Carsten as
 follows:

   "For the resource directory (RD) and related documents, we are aiming
   at WGLC before July 1st so we can discuss the outcome in Berlin and
   ship soon after.  There are quite a few things to do, many of which
   are on the editorial level (see slides, but also Akbar's "advanced
   RD" document; we will not try to put mirror server/pubsub support in
   the RD document now, though). The issues will managed on the WG
   tracker."

 https://www.ietf.org/mail-archive/web/core/current/msg07032.html

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-core-
  akbar.rahman@interdigital.com      |  resource-directory@tools.ietf.org
     Type:  protocol enhancement     |     Status:  new
 Priority:  major                    |  Milestone:
Component:  resource-directory       |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
core 


From nobody Wed Apr 27 19:03:54 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2512D0A9 for ; Wed, 27 Apr 2016 19:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.253
X-Spam-Level: 
X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] 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 0I-oqA8wNU1w for ; Wed, 27 Apr 2016 19:03:51 -0700 (PDT)
Received: from smtp-in1.interdigital.com (host-64-47-120-121.masergy.com [64.47.120.121]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF15D12B04E for ; Wed, 27 Apr 2016 19:03:51 -0700 (PDT)
X-ASG-Debug-ID: 1461809029-06daaa108799a90001-aa7cYp
Received: from NALENITE.InterDigital.com (nalenite.interdigital.com [10.2.64.253]) by smtp-in1.interdigital.com with ESMTP id Q1ttSi7wBxK0SXEA (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Apr 2016 22:03:49 -0400 (EDT)
X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com
Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NALENITE.InterDigital.com ([::1]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 22:03:49 -0400
From: "Rahman, Akbar" 
To: Michael Koster 
Thread-Topic: [core] #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD
X-ASG-Orig-Subj: RE: [core] #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD
Thread-Index: AQHRoPEzhAg9v5JTmUOrezH5TmjciJ+eoMlA
Date: Thu, 28 Apr 2016 02:03:48 +0000
Message-ID: <36F5869FE31AB24485E5E3222C288E1F5BAB2FAD@NABESITE.InterDigital.com>
References: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org>
In-Reply-To: <069.7523d7d325fef5bd8284a8441fb8863e@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.247.66]
x-exclaimer-md-config: bb79a19d-f711-475c-a0f9-4d93b71c94dd
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Barracuda-Connect: nalenite.interdigital.com[10.2.64.253]
X-Barracuda-Start-Time: 1461809029
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA
X-Barracuda-URL: https://10.1.245.3:443/cgi-mod/mark.cgi
X-Barracuda-Scan-Msg-Size: 2418
X-Virus-Scanned: by bsmtpd at interdigital.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.29119 Rule breakdown below pts rule name              description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO    Envelope rcpt doesn't match header
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] #406 (resource-directory): Consider URI ranking, Privacy Model, etc. as part of RD
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 02:03:53 -0000

Hi Mike,


I had an outstanding action from IETF-95 to create this ticket so we could =
have further discussion on which of the features out of draft-rahman-core-a=
dvanced-rd-features that we need for the first release of the RD:

https://tools.ietf.org/html/draft-rahman-core-advanced-rd-features-02


Any feedback would be appreciated.


/Akbar

-----Original Message-----
From: core issue tracker [mailto:trac+core@zinfandel.tools.ietf.org]
Sent: Wednesday, April 27, 2016 9:56 PM
To: draft-ietf-core-resource-directory@tools.ietf.org; Rahman, Akbar 
Cc: core@ietf.org
Subject: [core] #406 (resource-directory): Consider URI ranking, Privacy Mo=
del, etc. as part of RD

#406: Consider URI ranking, Privacy Model, etc. as part of RD

In IETF-95, there was a discussion regarding various enhancements to the  R=
D that should be considered as outlined in

https://tools.ietf.org/html/draft-rahman-core-advanced-rd-features-02

Examples of the enhancements included ranking of URI results from the RD  l=
ookup interface, and a clear privacy model for the RD lookup interface.


The conclusion of the discussion in IETF-95 was summarized by Carsten as
follows:

  "For the resource directory (RD) and related documents, we are aiming
  at WGLC before July 1st so we can discuss the outcome in Berlin and
  ship soon after.  There are quite a few things to do, many of which
  are on the editorial level (see slides, but also Akbar's "advanced
  RD" document; we will not try to put mirror server/pubsub support in
  the RD document now, though). The issues will managed on the WG
  tracker."

https://www.ietf.org/mail-archive/web/core/current/msg07032.html

--
-------------------------------------+----------------------------------
-------------------------------------+---
Reporter:                           |      Owner:  draft-ietf-core-
 akbar.rahman@interdigital.com      |  resource-directory@tools.ietf.org
    Type:  protocol enhancement     |     Status:  new
Priority:  major                    |  Milestone:
Component:  resource-directory       |    Version:
Severity:  -                        |   Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: 
core 


From nobody Thu Apr 28 00:21:33 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5281B12D0FA for ; Thu, 28 Apr 2016 00:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.597
X-Spam-Level: 
X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, 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 h2mTOoccQUov for ; Thu, 28 Apr 2016 00:21:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E72F12B030 for ; Thu, 28 Apr 2016 00:21:30 -0700 (PDT)
Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lp8h6-1baE922xJU-00epoy; Thu, 28 Apr 2016 09:21:16 +0200
To: Carsten Bormann , "core@ietf.org WG" , j.schoenwaelder@jacobs-university.de
References: <570A4583.2030100@tzi.org> <5718A09E.7040607@gmx.net>  <20160421174806.GA8710@elstar.local> <571D1E63.9090003@tzi.org> <571DEF4A.50506@gmx.net> <20160425103338.GA17158@elstar.local> <571DF986.6000200@gmx.net> <20160427070744.GA21138@elstar.local>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <5721B9F8.9070107@gmx.net>
Date: Thu, 28 Apr 2016 09:21:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160427070744.GA21138@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EKVK7VCMOAqfADEXV9vs5HxtmQq6eP9eG"
X-Provags-ID: V03:K0:eGVI50kSHt/VdepSC/pQOVrMgIZ2MQHoYcGvJJj8pCOPE/nM/HY IwxpZd8l7yYIiYjvdWyofDKqcH8PbW8RdziYtFJo6kNky3kuWYFjmjBR13HE2EeFhAtOAKB qoh3EHELFETIqvHEsVi4NYXHBO9spsqmgyZ9qLUU0CI1ncWjKjWdJihCUdMrWJaL0mCe5/p /tA6dWvBobckLIk34Whcw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:QxCrSb8CMbU=:ZceQ0Sgl5/z8saBAsRpmvD TB3THLSt1O9JdQRZSwunNTx0ptgR+Mx4B6x+YEIvyVHma61DuZfPeDvom511V37nSdQ30Uirt OHyM5y2SHWHSKxcQvOPgLsUNmMa+h7VvEhltz7z24M3YqTEigvW3Z5b0xFOYlZXVhcb0+NCzI KZXuD+m4Oi2cDn3LP9TKzvWC/hew1xfDUyAVaI8zj9W0FCXEfVoYtPT0eV1av5GJkjw1OdOun t/9JAPuqylZDnZi3EF/VvyiNesiN1ikxTHv9jlO7QjFf1B3eT4cRHjwqKQH3yuWjNZ7brP5r/ u8CFc6/chUhNPKBLMJ27W6ZjysXIblJwPVyjwUcUgi96YfzgS3K7HjIWMNp6EIzPZuA6+Kq8x KSXXT7ww8id/mN85vwPgDXXf4AhmJyqAHAkcFfhnMSTW+2Dg6elWeDrZ9wXtczq8AQdkY20NF 1G31P1hHJxvKdtqwLFYvvL3Y6LxqtIICAQKYiKg86U73BQqQPqiI2ZJ3+sZxmefjeXUnCKRDs bPSjtJ8frVSkZNnUEXKnsUBhhLgbtKZ0uYJVBzAT0L5IniuTqg2E+gCWRg+GjBUyYwb3UTpb6 lc6Ir6kv892rF6j9qzgePeB5c+Nj4wDZvl9NxZqTaaLNhnQd3dmKQVmX3QuPYULvuKetNhrrs 2d73WD96iJB0Imq+lQcQqdRE2zTlGumfXMbQ97vDRwzbhabrX1UeTdt3jWT7T3hu6pKo9RsuO 3vSyLDznwfd8XEjgEmWJwWXG9cpU/67k3mrMsrxHMBPPNAAbMlOEcGo5b3Y=
Archived-At: 
Subject: Re: [core] Using Yang to describe LWM2M ... was Re: ? WG adoption of draft-veillette-core-yang-cbor-mapping-00
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 07:21:32 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EKVK7VCMOAqfADEXV9vs5HxtmQq6eP9eG
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Juergen

thanks for your feedback.

What is considered 'open' seems to vary a bit. I was using the
definition of the OpenStand, see
https://open-stand.org/about-us/principles/

I will reach out to the OMA staff to find out why the current
boilerplate text exists.

Ciao
Hannes

On 04/27/2016 09:07 AM, Juergen Schoenwaelder wrote:
> On Mon, Apr 25, 2016 at 01:03:34PM +0200, Hannes Tschofenig wrote:
>> Hi Juergen,
>>
>> On 04/25/2016 12:33 PM, Juergen Schoenwaelder wrote:
>>> Hannes,
>>>
>>> whether this YANG fragment makes sense or not I simply do not know
>>> without knowing LWM2M and since there are no open specs there is
>>> little help you can expect. I have no clue about the interaction mode=
l
>>> of OMA LWM2M nor do I know what LWM2M_Device is etc.
>>
>> The specs are publically available for download at no cost.
>>
>> Here is the link:
>> http://technical.openmobilealliance.org/Technical/technical-informatio=
n/release-program/current-releases/oma-lightweightm2m-v1-0
>>
>> You want to look at the 'Technical Specification'.
>=20
> They are not open, I have to accept certain legal terms to get
> access. In particular:
>=20
>   use all or any part of a Document as part of a specification or
>   standard not emanating from the Licensor without the prior written
>   consent of the Licensor
>=20
> I might already need a written consent if I post an example here since
> everything posted to an IETF list may be considered a contribution.
> =20
>> The registry for the objects are also public and available in a nicely=

>> written page (similar to what IANA provides for the IETF):
>> http://technical.openmobilealliance.org/Technical/technical-informatio=
n/omna/lightweight-m2m-lwm2m-object-registry
>>
>=20
> Looking at examples to infer what the semantics of the schema are is
> not what I am going to spend my time on.
>=20
>> There is no permission that needs to be obtained IMHO, if I understand=

>> the OMA copyright policy correctly.
>=20
> See above.
>=20
> /js
>=20


--EKVK7VCMOAqfADEXV9vs5HxtmQq6eP9eG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJXIbn4AAoJEGhJURNOOiAtNwYH/3U2sbRsAhcubgSQlHmoLKNi
hZ5gU/T7pODhgTkwIaw0/LOlC+pJIyIwYRDmq/p6mG/mAbr/SIU67ufY6gTwH42r
HIykI30D1WjeCaMN8FDpWgaHDZ8a/GV3rATx0Mjrf6GH0k/hOg3+8CepoXmwlvEK
alrauh1aURQbuAn7ose/QuW8a/+I4ulKZCdfQZhPULdBxP8v2DJNnf0nGx1sW/jp
gUzS4jm+nv+R5G0PJzNsHy8qGVclcXrE+g2gmRjqU+76M191ki4/YrEsNE2xztfO
U50K5V1Gh53D84C1xV3jVAItJlLH4Q5sBeVJO9v8ytaYYZqLF7CYKOQF7B28/sg=
=oRvJ
-----END PGP SIGNATURE-----

--EKVK7VCMOAqfADEXV9vs5HxtmQq6eP9eG--


From nobody Thu Apr 28 01:03:58 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45212B052; Thu, 28 Apr 2016 01:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 FjVfI0Yh1eSt; Thu, 28 Apr 2016 01:03:54 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 878D112B02E; Thu, 28 Apr 2016 01:03:54 -0700 (PDT)
Received: from localhost ([::1]:59689 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1avgvR-0006T0-U8; Thu, 28 Apr 2016 01:03:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net
X-Trac-Project: core
Date: Thu, 28 Apr 2016 08:03:53 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/393#comment:1
Message-ID: <069.50ade6fe5f100d48ee251f73b5835072@trac.tools.ietf.org>
References: <054.5974ba2c6c5b8308b7df8f623c3e39e3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 393
In-Reply-To: <054.5974ba2c6c5b8308b7df8f623c3e39e3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap-tcp-tls@ietf.org, Hannes.Tschofenig@gmx.net, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-coap-tcp-tls@ietf.org
Resent-Message-Id: <20160428080354.878D112B02E@ietfa.amsl.com>
Resent-Date: Thu, 28 Apr 2016 01:03:54 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: Re: [core] #393 (coap-tcp-tls): Observing resource over reliable transports
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 08:03:57 -0000

#393: Observing resource over reliable transports


Comment (by Hannes.Tschofenig@gmx.net):

 In a conference call with Klaus, Simon, Bill and myself we discussed the
 issue and the raised questions.


 > QUESTION #1: Do servers need to include a sequence number in
 notifications, given that TCP/TLS provides reliable, in-order delivery?


 The text from the CoAP over Websockets could be re-used. Here is what it
 could say:

 ------

    Since the TCP provides ordered delivery of messages,
    the mechanism for reordering detection when observing resources
    [RFC7641] is not needed.  The value of the Observe Option in
    notifications therefore MAY be empty on transmission and MUST be
    ignored on reception.

 ------

 The Observe Option still has to be sent since it contains other
 information as well.

 > QUESTION #2: Does a client have to re-register its interest in a
 resource if it hasn't received a notification for a while but the
 connection is still up?

 We believe it is enough to send keep-alive message for the CoAP over TCP
 draft
 (as opposed to send a re-registration message when used over UDP).

 > QUESTION #3: How do servers throttle the stream of notifications when
 the resource changes its state more frequently than the server can send
 notifications?

 TCP offers a flow control mechanism as a means for the receiver to govern
 the amount of data sent by the sender. This is functionality that can be
 re-used.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-coap-tcp-
  hartke@tzi.org         |  tls@ietf.org
     Type:  other        |      Status:  new
  technical              |   Milestone:
 Priority:  minor        |     Version:
Component:  coap-tcp-    |  Resolution:
  tls                    |
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
core 


From nobody Thu Apr 28 02:43:00 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA53812D0F0 for ; Thu, 28 Apr 2016 02:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level: 
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsLkc6QW7Yhf for ; Thu, 28 Apr 2016 02:42:56 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B6F9312B054 for ; Thu, 28 Apr 2016 02:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1461836576; d=isode.com; s=selector; i=@isode.com; bh=IyXiCnOqQ0BiiyEbyAo7DktkNZaIYpWa+UHAoiEX0vc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fj0y5lY/6Z63Bx8PuQooiIua1OuJIzPsBjrgmJLLvVlsFDFo82Xif9F+FQDIJUIjmuYMKs D5LDOOOP/410lBZ5A/nm8iagh2zJByzT2sz9SZSaVMtOlSx9go7zgUl1xs2jZFaFgN1InC Tc3P2fCw/cE2DVAIBK0KXf5T1HkaOEY=;
Received: from [10.232.42.149] ((unknown) [185.69.144.237])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Thu, 28 Apr 2016 10:42:55 +0100
X-SMTP-Protocol-Errors: NORDNS PIPELINING
From: Alexey Melnikov 
Date: Thu, 28 Apr 2016 10:47:46 +0100
Message-Id: <52F80F7B-FD08-4C17-8F9C-66BFACEBBF81@isode.com>
To: core@ietf.org
X-Mailer: iPhone Mail (13E238)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [core] New co-chair for CORE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 09:42:58 -0000

Thank you to Jaime Jim=C3=A9nez for agreeing to co-chair CORE together with C=
arsten.
I am looking forward to reviewing more CORE documents for IESG.


From nobody Thu Apr 28 02:56:35 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8832112D629 for ; Thu, 28 Apr 2016 02:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7bHQb1H_KPq for ; Thu, 28 Apr 2016 02:56:32 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C491A12D62A for ; Thu, 28 Apr 2016 02:56:31 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-00-5721de4dfdd7
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.F9.18043.D4ED1275; Thu, 28 Apr 2016 11:56:29 +0200 (CEST)
Received: from ESESSMB307.ericsson.se ([169.254.7.203]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 11:55:36 +0200
From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= 
To: Alexey Melnikov 
Thread-Topic: New co-chair for CORE
Thread-Index: AQHRoTJYkukOQImhVECSw0bRI2WOUp+fBEoA
Date: Thu, 28 Apr 2016 09:55:34 +0000
Message-ID: 
References: <52F80F7B-FD08-4C17-8F9C-66BFACEBBF81@isode.com>
In-Reply-To: <52F80F7B-FD08-4C17-8F9C-66BFACEBBF81@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/signed; boundary="Apple-Mail=_A90E94AD-C86D-45A9-A561-AC6D763F569D"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7pa7vPcVwgzv/NCxmrC6y2Pd2PbMD k8eSJT+ZPE41GwYwRXHZpKTmZJalFunbJXBlnH32nK3gpEHFiWcf2RsYT+h1MXJySAiYSCzZ sYwdwhaTuHBvPVsXIxeHkMARRqDEMxYIZwmjxP2GjWwgVWwCzhKfnjWCdYgI6EusfjWLBcRm FlCWOD77MGsXIweHsICSxOd9diCmCFD4xwIHiGojiVfvt7KC2CwCqhKbpt8Fq+YVsJd4/l4a JCwkYCNxe/YCsBJOAVuJRVP6mUBsRqDTvp9awwSxSFzi1pP5TBAni0g8vHiaDcIWlXj5+B8r hK0ksWL7JUaQ65kFpjBKLOhcAZbgFRCUODnzCcsERtFZSGbNQlY3C0kdRJG2xLKFr5khbE2J /d3LoeKmEq+PfmSEsK0lZvw6yAZhK0pM6X7IvoCRYxWjaHFqcXFuupGRXmpRZnJxcX6eXl5q ySZGYAwe3PLbagfjweeOhxgFOBiVeHgX5CmGC7EmlhVX5h5iVAGa82jD6guMUix5+XmpSiK8 GneB0rwpiZVVqUX58UWlOanFhxilOViUxHlzIv+FCQmkJ5akZqemFqQWwWSZODilGhi1knL3 yNuFzf/wIOqwsH5P3cnautcZlzw1jiycfGPNkt8SE81keBjnW9VtnWa75tnFfesXKXeX3CuJ 1Ql1vKnaXCuxqHR2+pqVS6xdX2+IiyxxaljyL39SKdPuTompUfteOWezzUiq9lSRveKZs+vF veUFBvnnc6riVP0sFWv/s/f//btccpESS3FGoqEWc1FxIgDr0cd8yQIAAA==
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] New co-chair for CORE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 09:56:33 -0000

--Apple-Mail=_A90E94AD-C86D-45A9-A561-AC6D763F569D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

Thanks, very happy to be aboard and looking forward to help on =
completing the work.

Ciao!
- - Jaime Jimenez

> On 28 Apr 2016, at 12:47, Alexey Melnikov  =
wrote:
>=20
> Thank you to Jaime Jim=C3=A9nez for agreeing to co-chair CORE together =
with Carsten.
> I am looking forward to reviewing more CORE documents for IESG.
>=20


--Apple-Mail=_A90E94AD-C86D-45A9-A561-AC6D763F569D
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w
ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp
Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy
MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg
Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD
VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr
VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53
Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv
lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd
gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2
SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny
bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH
AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF
BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w
TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0
LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud
DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L
NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH
+bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz
yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX
nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR
7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp
SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil
DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8
BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy
bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C
hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb
mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV
BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx
WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD
QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs
MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf
Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA
cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA
mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI
UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP
5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF
nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1
41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe
aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB
BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w
SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp
YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB
BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv
bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv
bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD
VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9
kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg
36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX
g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ
6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k
XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5
tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6
n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh
+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr
ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC
AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh
bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjgwOTU1MzVaMCMGCSqGSIb3DQEJBDEWBBRf
q5PpHVVxoEG/RYuXPNtY8dMxvjBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u
MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q
MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz
b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC
AQCBrW2SCv1UfDgIQCWimxpPsY2sBGoQ3+S2CHlvEEIs7swqCb/Ql8ruYGD1PE1MG0mY9lnZffJn
duBtXfxyVsfAzxhbs5eifDeugvLXO4172hk5Wngrz0qLilh/GRlRXEMykp1Gg58yurs7HtluClfM
xwzBzv0CERzVDmtsiFA7+lHMi2k9mPptIpxgsy0ApuGaUtEf52gbQVIKhv/DhG4C6R/2dS6+80rq
wMk677RchuzuPJwv0m/JRDDNBaXqfFiPfv2n6vG6/IAd572Mh9OhhKLNuRGwGrvHJLJSbwDaECyr
p/oncF4eo77o8c8LhFrUdpIvVgF/5OBdCTHt72PWAAAAAAAA

--Apple-Mail=_A90E94AD-C86D-45A9-A561-AC6D763F569D--


From nobody Thu Apr 28 07:05:39 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4BB12D5B8 for ; Thu, 28 Apr 2016 07:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3O3qkNdpYtR for ; Thu, 28 Apr 2016 07:05:31 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D7B12D195 for ; Thu, 28 Apr 2016 07:05:30 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-1f-572218a83417
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.4F.12516.8A812275; Thu, 28 Apr 2016 16:05:28 +0200 (CEST)
Received: from ESESSMB307.ericsson.se ([169.254.7.203]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 16:05:11 +0200
From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= 
To: "core@ietf.org" 
Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmFuZGVyc3Rvay1j?= =?utf-8?Q?ore-etch-00?=
Thread-Index: AQHRoVb6SK7lqolnjUiqskJPlIsdww==
Date: Thu, 28 Apr 2016 14:05:10 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/signed; boundary="Apple-Mail=_9C1EAA1E-3ACF-4CEF-97C6-66AA44806F00"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdWHeFhFK4wbPbRhb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv1tE9gLJhhVfPwwia2B8Yl+FyMnh4SAicSFH0+YIGwxiQv3 1rN1MXJxCAkcYZR4OXUZM0hCSGAJo8SFZxkgNpuAs8SnZ43sILaIgLLE5jOvGUFsYYFsiTNn j7NAxAskFqxdDTSUA8jWk3h2URIkzCKgKnH042Swcl4Be6DW/WBjGIH2fj+1BuwGZgFxiVtP 5kPdIyLx8OJpNghbVOLl43+sELaSxKLbn5lA7mQWmMIocbdtEjPEUEGJkzOfsExgFJqFZNYs ZHWzkNRBFGlLLFv4GijOAWTrSExeyAgRNpV4ffQjlG0tMePXQTYIW1FiSvdD9gWMHKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAmPl4JbfujsYV792PMQowMGoxMO7IE8xXIg1say4MvcQ owrQnEcbVl9glGLJy89LVRLhfSKuFC7Em5JYWZValB9fVJqTWnyIUZqDRUmc1/8lUKdAemJJ anZqakFqEUyWiYNTqoExpL4qdMvOS8oJ026/shaI4/pwKc3D3mF3pXb90m72tUedFvhxnJDk SeVeV+yuKCpzQ3+y9FeHedF/SiTLzQ+lmPAtWjJxW02E0ZsTt1btc13Mmhs8aapLs2dCpsk8 ZhdOn7zbfBP++cy5zPk18BVfSIDy+fU5atGdnQc2l1m0ZekaG6d9qFJiKc5INNRiLipOBAAD jbMDnQIAAA==
Archived-At: 
Subject: [core] =?utf-8?q?_=F0=9F=94=94_WG_adoption_of_draft-vanderstok-co?= =?utf-8?q?re-etch-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 14:05:37 -0000

--Apple-Mail=_9C1EAA1E-3ACF-4CEF-97C6-66AA44806F00
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

going through the item list, in Buenos Aires we discussed the adoption =
of draft-vanderstok-core-etch-00 as WG item. Back then there was room =
consensus with 12 people in favor (+ 4 more on the jabber) and noone =
against.=20

This work is needed in order to keep using PATCH link updates on the RD =
and also for the COMI work that has already been adopted as of this =
week.=20

This is a one-week call for confirmation on that decision, so if there =
are objections please voice them on the mailing list by 2016-05-06.

Ciao,
- - Jaime Jimenez


--Apple-Mail=_9C1EAA1E-3ACF-4CEF-97C6-66AA44806F00
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w
ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp
Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy
MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg
Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD
VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr
VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53
Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv
lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd
gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2
SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny
bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH
AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF
BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w
TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0
LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud
DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L
NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH
+bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz
yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX
nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR
7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp
SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil
DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8
BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy
bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C
hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb
mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV
BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx
WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD
QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs
MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf
Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA
cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA
mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI
UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP
5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF
nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1
41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe
aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB
BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w
SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp
YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB
BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv
bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv
bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD
VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9
kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg
36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX
g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ
6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k
XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5
tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6
n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh
+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr
ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC
AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh
bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjgxNDA1MTBaMCMGCSqGSIb3DQEJBDEWBBRZ
LPcFaGFK1/yQNnsPL6R5R95TpTBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u
MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q
MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz
b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC
AQA61Qxnr+FFs2mKK537QppioSncl4wHRz1wpvipMpDn5WU8yfKH36QNdN708cWrdIUK/3oOJ9R6
ypREQVJ4y+d24oL5roDF4D0eTWjdwNQqBOqMWP3jYGfeRAQ7Z3NHHxiVGph+JImIQxjqaKV5qGCN
TXy04Nk6lAOU9HL8BAkoeJtqM+GnOfWCMfXOCYDTwWGsb8MWokv3qP354wUSRfd8iozGIc+K93tJ
CpOM1x1VIjz8II3Tt3jaKM5EYuCbsZPRSDvavY34Dt1v7oNVhvC31TniOk4YSzSSkZElol4LwIhs
Eyoyo36997AmrB5OlgPpXpunHF7d/XwkT3461QU/AAAAAAAA

--Apple-Mail=_9C1EAA1E-3ACF-4CEF-97C6-66AA44806F00--


From nobody Thu Apr 28 07:51:50 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345C812D7EF for ; Thu, 28 Apr 2016 07:51:50 -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] 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 vJTouV3dRId5 for ; Thu, 28 Apr 2016 07:51:47 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3DB12D7D0 for ; Thu, 28 Apr 2016 07:51:47 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:ad51:ac04:6256:1a82] (unknown [IPv6:2001:660:7301:3728:ad51:ac04:6256:1a82]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id EBA54172101; Thu, 28 Apr 2016 16:51:45 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alexander Pelov 
In-Reply-To: 
Date: Thu, 28 Apr 2016 16:52:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6000D470-4534-4EB1-A644-307E30203D6E@ackl.io>
References: 
To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-vanderstok-cor?= =?utf-8?q?e-etch-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 14:51:50 -0000

Dear all,

I am in favor for adopting the document as a WG item.

Both FETCH and PATCH are adding missing functionality to the set of =
standard CoAP verbs. They provide semantics which are already present in =
standard HTTP, or that will be standardized soon.

For non-constrained networks and/or devices their lack may be a matter =
of personal feelings or slight inconveniences. For constrained networks =
or constrained devices, their addition provides powerful methods to =
significantly limit the data sent on the air + simplify the APIs. The =
functionality provided by FETCH and PATCH could be to some extent =
emulated with POSTs, but many of the benefits we have from RESTful =
applications are lost.=20

Through the design of the function set of the latest COMI/COOL proposal, =
we=E2=80=99ve passed through several iterations and we=E2=80=99ve =
investigated FETCH+PATCH approach VS no-FETCH and no-PATCH solution. The =
latter required introducing new CoAP option and was generally more =
complex. Some things were simply impossible without the use of POST.

My personal take on this is: we need FETCH and PATCH. The work on the =
document advances very well and there are several key people actively =
contributing to it.=20

+1

Best,
Alexander

> Le 28 avr. 2016 =C3=A0 16:05, Jaime Jim=C3=A9nez =
 a =C3=A9crit :
>=20
> Hi all,
>=20
> going through the item list, in Buenos Aires we discussed the adoption =
of draft-vanderstok-core-etch-00 as WG item. Back then there was room =
consensus with 12 people in favor (+ 4 more on the jabber) and noone =
against.=20
>=20
> This work is needed in order to keep using PATCH link updates on the =
RD and also for the COMI work that has already been adopted as of this =
week.=20
>=20
> This is a one-week call for confirmation on that decision, so if there =
are objections please voice them on the mailing list by 2016-05-06.
>=20
> Ciao,
> - - Jaime Jimenez
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Thu Apr 28 08:39:01 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0712D837 for ; Thu, 28 Apr 2016 08:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 db35BMe34td4 for ; Thu, 28 Apr 2016 08:38:56 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08DD12D8FB for ; Thu, 28 Apr 2016 08:36:41 -0700 (PDT)
Received: from [IPv6:2001:660:7301:3728:ad51:ac04:6256:1a82] (unknown [IPv6:2001:660:7301:3728:ad51:ac04:6256:1a82]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 9312A172220; Thu, 28 Apr 2016 17:36:39 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alexander Pelov 
In-Reply-To: 
Date: Thu, 28 Apr 2016 17:37:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CE32D15-561F-4643-A1B3-726F58980D21@ackl.io>
References: <52F80F7B-FD08-4C17-8F9C-66BFACEBBF81@isode.com> 
To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= , andrewmcgr@gmail.com
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] New co-chair for CORE
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 15:39:00 -0000

Dear Andrew,=20
Thanks, for all you contributions!=20

Dear Jaime,=20
Welcome! Thanks for agreeing to co-chair the group!

We have a lot of important topics to work on and I am confident we will =
do great together!

Best,
Alexander



> Le 28 avr. 2016 =C3=A0 11:55, Jaime Jim=C3=A9nez =
 a =C3=A9crit :
>=20
> Hi,
>=20
> Thanks, very happy to be aboard and looking forward to help on =
completing the work.
>=20
> Ciao!
> - - Jaime Jimenez
>=20
>> On 28 Apr 2016, at 12:47, Alexey Melnikov  =
wrote:
>>=20
>> Thank you to Jaime Jim=C3=A9nez for agreeing to co-chair CORE =
together with Carsten.
>> I am looking forward to reviewing more CORE documents for IESG.
>>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From nobody Thu Apr 28 09:00:05 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47E412DA07 for ; Thu, 28 Apr 2016 09:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkKIBSjcMEGZ for ; Thu, 28 Apr 2016 09:00:00 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D686A12D958 for ; Thu, 28 Apr 2016 08:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jWxeyVzp9JMMRpn41VMNgSPCZM1A8w3PvnA73toK7FU=; b=VeV5qPSaWMPeD2t5IArkbsnXZDTxnMqWCg4Mr+smt7OF+NVd50joCA2+meYuiiXpOV92eh5kbEQNWKMUXwLgmXsaE4XkT3FdJ5by5gXz3NpqrCmIPkZoEBKfllsIL+XyRaNljnrYMX0FtlUDxg5uw2Wahc1rlB1UQRI/tRMl6fc=
Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (TLS) id 15.1.477.8; Thu, 28 Apr 2016 15:53:16 +0000
Received: from BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) by BLUPR06MB1763.namprd06.prod.outlook.com ([10.162.224.149]) with mapi id 15.01.0477.014; Thu, 28 Apr 2016 15:53:16 +0000
From: Michel Veillette 
To: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= 
Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmFuZGVyc3Rvay1j?= =?utf-8?Q?ore-etch-00?=
Thread-Index: AQHRoV2C8eNneB8lg0GtuJCnx98XD5+fh7Rg
Date: Thu, 28 Apr 2016 15:53:15 +0000
Message-ID: 
References:  <6000D470-4534-4EB1-A644-307E30203D6E@ackl.io>
In-Reply-To: <6000D470-4534-4EB1-A644-307E30203D6E@ackl.io>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=trilliantinc.com;
x-originating-ip: [207.96.192.122]
x-ms-office365-filtering-correlation-id: 684e2672-beb5-4b84-efc4-08d36f7d364e
x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:24hJ3FQmxNJL+sIVjFkNMawJVQUSBDJOdVovrSD+88nqtzttbNQbh7KSFiylBV2ZmBfD6Vqx2bxEkF3Py2ZT6vaXY25QOri8gvXNkgscOoBaYco3+vxWmAu9m9YHcbCqD/3GrXvNufTb9DXm8rXGdQ==; 24:5wEZ/vE9BOQoL43UywJruOq8dxZNfX4LvEGpdZk6Rx/puodOj2reoxDsdrfEDuKeQCTEX3ofJDXMRJ/G7ezcwEpytCGFiE+Z0B6aAWeQI0M=; 7:bsNmCqqnUphNJYMk+cXhl0pFA54jVcXKTMDapLJzolihhGgFmX22w+SHa5D+id5SxnNOhX6fYJ+PCg4Rdso1EqP1uwCXT2FPsNELnDqLJQfU25kQMi63ITunoSaldSRwwbZYqWzQnfMc8FT6fVCopfYa0Il3zjE2K8nw7UOJvN4PyZPhZwRdPzfetN11YU3U
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; 
x-forefront-prvs: 0926B0E013
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(53754006)(229383001)(86362001)(99286002)(106116001)(5004730100002)(81166005)(74316001)(3660700001)(66066001)(15975445007)(77096005)(4326007)(19580395003)(2900100001)(19580405001)(3280700002)(189998001)(110136002)(5003600100002)(2906002)(9686002)(5002640100001)(92566002)(586003)(3846002)(2950100001)(6116002)(122556002)(102836003)(76176999)(50986999)(54356999)(1096002)(5008740100001)(33656002)(10400500002)(87936001)(1220700001)(561944003)(230783001)(76576001)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: trilliantinc.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 15:53:16.0234 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-vanderstok-cor?= =?utf-8?q?e-etch-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 16:00:03 -0000

KzENCg0KVXNlZnVsIG1ldGhvZHMgdG8gYWNjZXNzIHJlc291cmNlIHN1YnNldC4NClVzZSBpbiBD
b01JL0NvT0wgdG8gaW1wbGVtZW50IGFuIGF0b21pYyB1cGRhdGUgYW5kIGEgcGFydGlhbCByZXRy
aWV2YWwgb2YgYSBkYXRhc3RvcmUuDQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgUGVsb3YNClNlbnQ6IEFwcmlsLTI4LTE2IDEwOjUyIEFN
DQpUbzogSmFpbWUgSmltw6luZXogPGphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tPg0KQ2M6IGNv
cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFm
dC12YW5kZXJzdG9rLWNvcmUtZXRjaC0wMA0KDQpEZWFyIGFsbCwNCg0KSSBhbSBpbiBmYXZvciBm
b3IgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGFzIGEgV0cgaXRlbS4NCg0KQm90aCBGRVRDSCBhbmQg
UEFUQ0ggYXJlIGFkZGluZyBtaXNzaW5nIGZ1bmN0aW9uYWxpdHkgdG8gdGhlIHNldCBvZiBzdGFu
ZGFyZCBDb0FQIHZlcmJzLiBUaGV5IHByb3ZpZGUgc2VtYW50aWNzIHdoaWNoIGFyZSBhbHJlYWR5
IHByZXNlbnQgaW4gc3RhbmRhcmQgSFRUUCwgb3IgdGhhdCB3aWxsIGJlIHN0YW5kYXJkaXplZCBz
b29uLg0KDQpGb3Igbm9uLWNvbnN0cmFpbmVkIG5ldHdvcmtzIGFuZC9vciBkZXZpY2VzIHRoZWly
IGxhY2sgbWF5IGJlIGEgbWF0dGVyIG9mIHBlcnNvbmFsIGZlZWxpbmdzIG9yIHNsaWdodCBpbmNv
bnZlbmllbmNlcy4gRm9yIGNvbnN0cmFpbmVkIG5ldHdvcmtzIG9yIGNvbnN0cmFpbmVkIGRldmlj
ZXMsIHRoZWlyIGFkZGl0aW9uIHByb3ZpZGVzIHBvd2VyZnVsIG1ldGhvZHMgdG8gc2lnbmlmaWNh
bnRseSBsaW1pdCB0aGUgZGF0YSBzZW50IG9uIHRoZSBhaXIgKyBzaW1wbGlmeSB0aGUgQVBJcy4g
VGhlIGZ1bmN0aW9uYWxpdHkgcHJvdmlkZWQgYnkgRkVUQ0ggYW5kIFBBVENIIGNvdWxkIGJlIHRv
IHNvbWUgZXh0ZW50IGVtdWxhdGVkIHdpdGggUE9TVHMsIGJ1dCBtYW55IG9mIHRoZSBiZW5lZml0
cyB3ZSBoYXZlIGZyb20gUkVTVGZ1bCBhcHBsaWNhdGlvbnMgYXJlIGxvc3QuIA0KDQpUaHJvdWdo
IHRoZSBkZXNpZ24gb2YgdGhlIGZ1bmN0aW9uIHNldCBvZiB0aGUgbGF0ZXN0IENPTUkvQ09PTCBw
cm9wb3NhbCwgd2XigJl2ZSBwYXNzZWQgdGhyb3VnaCBzZXZlcmFsIGl0ZXJhdGlvbnMgYW5kIHdl
4oCZdmUgaW52ZXN0aWdhdGVkIEZFVENIK1BBVENIIGFwcHJvYWNoIFZTIG5vLUZFVENIIGFuZCBu
by1QQVRDSCBzb2x1dGlvbi4gVGhlIGxhdHRlciByZXF1aXJlZCBpbnRyb2R1Y2luZyBuZXcgQ29B
UCBvcHRpb24gYW5kIHdhcyBnZW5lcmFsbHkgbW9yZSBjb21wbGV4LiBTb21lIHRoaW5ncyB3ZXJl
IHNpbXBseSBpbXBvc3NpYmxlIHdpdGhvdXQgdGhlIHVzZSBvZiBQT1NULg0KDQpNeSBwZXJzb25h
bCB0YWtlIG9uIHRoaXMgaXM6IHdlIG5lZWQgRkVUQ0ggYW5kIFBBVENILiBUaGUgd29yayBvbiB0
aGUgZG9jdW1lbnQgYWR2YW5jZXMgdmVyeSB3ZWxsIGFuZCB0aGVyZSBhcmUgc2V2ZXJhbCBrZXkg
cGVvcGxlIGFjdGl2ZWx5IGNvbnRyaWJ1dGluZyB0byBpdC4gDQoNCisxDQoNCkJlc3QsDQpBbGV4
YW5kZXINCg0KPiBMZSAyOCBhdnIuIDIwMTYgw6AgMTY6MDUsIEphaW1lIEppbcOpbmV6IDxqYWlt
ZS5qaW1lbmV6QGVyaWNzc29uLmNvbT4gYSDDqWNyaXQgOg0KPiANCj4gSGkgYWxsLA0KPiANCj4g
Z29pbmcgdGhyb3VnaCB0aGUgaXRlbSBsaXN0LCBpbiBCdWVub3MgQWlyZXMgd2UgZGlzY3Vzc2Vk
IHRoZSBhZG9wdGlvbiBvZiBkcmFmdC12YW5kZXJzdG9rLWNvcmUtZXRjaC0wMCBhcyBXRyBpdGVt
LiBCYWNrIHRoZW4gdGhlcmUgd2FzIHJvb20gY29uc2Vuc3VzIHdpdGggMTIgcGVvcGxlIGluIGZh
dm9yICgrIDQgbW9yZSBvbiB0aGUgamFiYmVyKSBhbmQgbm9vbmUgYWdhaW5zdC4gDQo+IA0KPiBU
aGlzIHdvcmsgaXMgbmVlZGVkIGluIG9yZGVyIHRvIGtlZXAgdXNpbmcgUEFUQ0ggbGluayB1cGRh
dGVzIG9uIHRoZSBSRCBhbmQgYWxzbyBmb3IgdGhlIENPTUkgd29yayB0aGF0IGhhcyBhbHJlYWR5
IGJlZW4gYWRvcHRlZCBhcyBvZiB0aGlzIHdlZWsuIA0KPiANCj4gVGhpcyBpcyBhIG9uZS13ZWVr
IGNhbGwgZm9yIGNvbmZpcm1hdGlvbiBvbiB0aGF0IGRlY2lzaW9uLCBzbyBpZiB0aGVyZSBhcmUg
b2JqZWN0aW9ucyBwbGVhc2Ugdm9pY2UgdGhlbSBvbiB0aGUgbWFpbGluZyBsaXN0IGJ5IDIwMTYt
MDUtMDYuDQo+IA0KPiBDaWFvLA0KPiAtIC0gSmFpbWUgSmltZW5leg0KPiANCj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxp
c3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg==


From nobody Thu Apr 28 11:11:58 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959F412D1CB for ; Thu, 28 Apr 2016 11:11:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zgrp.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 HPQmqCUlK7qc for ; Thu, 28 Apr 2016 11:11:54 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CC512B047 for ; Thu, 28 Apr 2016 11:11:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zgrp.onmicrosoft.com;  s=selector1-tridonic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IRJuOqysAzrDpbrQcUgE24Kqo7UfDQZDTN76DqsFq9Q=; b=J0Xzib/fPhKxqGsnAKR6pzg4LPHSUi0tXXool+PNH2TwEdNAKULgZUWt8n0IxXv6OFvy7Ok/Y7QhueYgA3g2vKETt7G3deZsql8XgwoK3lTJVry48gM1N2y+uvPgo/aYPnqGhvizo44lzXs9gFG28YLcaXFKT0uLx8ii7g2vZcU=
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com (10.165.237.157) by VI1PR06MB1838.eurprd06.prod.outlook.com (10.165.237.156) with Microsoft SMTP Server (TLS) id 15.1.485.3; Thu, 28 Apr 2016 18:11:36 +0000
Received: from VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) by VI1PR06MB1839.eurprd06.prod.outlook.com ([10.165.237.157]) with mapi id 15.01.0485.005; Thu, 28 Apr 2016 18:11:36 +0000
From: Somaraju Abhinav 
To: Alexander Pelov , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= 
Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmFuZGVyc3Rvay1j?= =?utf-8?Q?ore-etch-00?=
Thread-Index: AQHRoV2COz/VPHtNy0qptkeT0fH8UJ+fsBK6
Date: Thu, 28 Apr 2016 18:11:36 +0000
Message-ID: 
References: , <6000D470-4534-4EB1-A644-307E30203D6E@ackl.io>
In-Reply-To: <6000D470-4534-4EB1-A644-307E30203D6E@ackl.io>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=tridonic.com;
x-originating-ip: [89.144.202.39]
x-ms-office365-filtering-correlation-id: 450447b0-468a-46d1-eeb5-08d36f908991
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1838; 5:KnRGly32C9vOI36z1px8c1RkBQmz9GIio6jgQ3LN2nWQ8jQ60bbEM7RhaiuotyQfVH4iFP0FdAgYj7RIe4zvR5n+LOcrShayiCUjC+3p4viNgaBfFxeEs304VyNZN/XZth99+9B10/JlDnR0UyUtRw==; 24:xKNJAyUgvYAyJ95FD4dH8iiop7cjDuKsaS2QKlERItLRM62CWZgC05du98HXZG8NlGjupcEdv4nA7nKs9hwVZ+o1j9aL0QQmh+V/jv7jUMc=; 7:D2j8a/tnIMuGf3K1o7FOZrn9iRbxdLs5flrG6MqNtOItnjKQRhFtj9hDzuUi321kdI2jsVOFLPNdc0HSgWBUy+7B5o7nhVWZi0AzT+HYZALkAkCy53RcWjxbCKg3ug/wqFiRBXO5ESsJtOsQv4X+wsdQD/GuuUJOHoNb3mQdtXytTUlWFo8neBBwDKeZolpt
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1838;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:VI1PR06MB1838; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1838; 
x-forefront-prvs: 0926B0E013
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(33656002)(3900700001)(3280700002)(66066001)(16236675004)(92566002)(19617315012)(122556002)(3660700001)(74316001)(561944003)(86362001)(230783001)(102836003)(19625215002)(5004730100002)(2906002)(586003)(9886003)(6116002)(9686002)(3846002)(76576001)(2900100001)(77096005)(81166005)(4326007)(5003600100002)(229383001)(5890100001)(5002640100001)(15975445007)(189998001)(5001770100001)(10400500002)(1096002)(2950100001)(87936001)(19580405001)(106116001)(1220700001)(5008740100001)(54356999)(11100500001)(76176999)(50986999)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1838; H:VI1PR06MB1839.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR06MB1839420357E212CD42FDF6C6FC650VI1PR06MB1839eurp_"
MIME-Version: 1.0
X-OriginatorOrg: tridonic.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2016 18:11:36.1825 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8b206608-a593-4ace-a4b6-ef1fc83c9169
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1838
Archived-At: 
Cc: "core@ietf.org" 
Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WG_adoption_of_draft-vanderstok-cor?= =?utf-8?q?e-etch-00?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 18:11:57 -0000

--_000_VI1PR06MB1839420357E212CD42FDF6C6FC650VI1PR06MB1839eurp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzEgZm9yIHRoZSBzYW1lIHJlYXNvbnMgTWljaGVsIGhhcy4NCg0KU2VudCBmcm9tIG15IFdpbmRv
d3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBbGV4YW5k
ZXIgUGVsb3Y8bWFpbHRvOmFAYWNrbC5pbz4NClNlbnQ6IOKAjjI4L+KAjjA0L+KAjjIwMTYgMTY6
NTENClRvOiBKYWltZSBKaW3DqW5lejxtYWlsdG86amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+
DQpDYzogY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
Y29yZV0g8J+UlCBXRyBhZG9wdGlvbiBvZiBkcmFmdC12YW5kZXJzdG9rLWNvcmUtZXRjaC0wMA0K
DQpEZWFyIGFsbCwNCg0KSSBhbSBpbiBmYXZvciBmb3IgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGFz
IGEgV0cgaXRlbS4NCg0KQm90aCBGRVRDSCBhbmQgUEFUQ0ggYXJlIGFkZGluZyBtaXNzaW5nIGZ1
bmN0aW9uYWxpdHkgdG8gdGhlIHNldCBvZiBzdGFuZGFyZCBDb0FQIHZlcmJzLiBUaGV5IHByb3Zp
ZGUgc2VtYW50aWNzIHdoaWNoIGFyZSBhbHJlYWR5IHByZXNlbnQgaW4gc3RhbmRhcmQgSFRUUCwg
b3IgdGhhdCB3aWxsIGJlIHN0YW5kYXJkaXplZCBzb29uLg0KDQpGb3Igbm9uLWNvbnN0cmFpbmVk
IG5ldHdvcmtzIGFuZC9vciBkZXZpY2VzIHRoZWlyIGxhY2sgbWF5IGJlIGEgbWF0dGVyIG9mIHBl
cnNvbmFsIGZlZWxpbmdzIG9yIHNsaWdodCBpbmNvbnZlbmllbmNlcy4gRm9yIGNvbnN0cmFpbmVk
IG5ldHdvcmtzIG9yIGNvbnN0cmFpbmVkIGRldmljZXMsIHRoZWlyIGFkZGl0aW9uIHByb3ZpZGVz
IHBvd2VyZnVsIG1ldGhvZHMgdG8gc2lnbmlmaWNhbnRseSBsaW1pdCB0aGUgZGF0YSBzZW50IG9u
IHRoZSBhaXIgKyBzaW1wbGlmeSB0aGUgQVBJcy4gVGhlIGZ1bmN0aW9uYWxpdHkgcHJvdmlkZWQg
YnkgRkVUQ0ggYW5kIFBBVENIIGNvdWxkIGJlIHRvIHNvbWUgZXh0ZW50IGVtdWxhdGVkIHdpdGgg
UE9TVHMsIGJ1dCBtYW55IG9mIHRoZSBiZW5lZml0cyB3ZSBoYXZlIGZyb20gUkVTVGZ1bCBhcHBs
aWNhdGlvbnMgYXJlIGxvc3QuDQoNClRocm91Z2ggdGhlIGRlc2lnbiBvZiB0aGUgZnVuY3Rpb24g
c2V0IG9mIHRoZSBsYXRlc3QgQ09NSS9DT09MIHByb3Bvc2FsLCB3ZeKAmXZlIHBhc3NlZCB0aHJv
dWdoIHNldmVyYWwgaXRlcmF0aW9ucyBhbmQgd2XigJl2ZSBpbnZlc3RpZ2F0ZWQgRkVUQ0grUEFU
Q0ggYXBwcm9hY2ggVlMgbm8tRkVUQ0ggYW5kIG5vLVBBVENIIHNvbHV0aW9uLiBUaGUgbGF0dGVy
IHJlcXVpcmVkIGludHJvZHVjaW5nIG5ldyBDb0FQIG9wdGlvbiBhbmQgd2FzIGdlbmVyYWxseSBt
b3JlIGNvbXBsZXguIFNvbWUgdGhpbmdzIHdlcmUgc2ltcGx5IGltcG9zc2libGUgd2l0aG91dCB0
aGUgdXNlIG9mIFBPU1QuDQoNCk15IHBlcnNvbmFsIHRha2Ugb24gdGhpcyBpczogd2UgbmVlZCBG
RVRDSCBhbmQgUEFUQ0guIFRoZSB3b3JrIG9uIHRoZSBkb2N1bWVudCBhZHZhbmNlcyB2ZXJ5IHdl
bGwgYW5kIHRoZXJlIGFyZSBzZXZlcmFsIGtleSBwZW9wbGUgYWN0aXZlbHkgY29udHJpYnV0aW5n
IHRvIGl0Lg0KDQorMQ0KDQpCZXN0LA0KQWxleGFuZGVyDQoNCj4gTGUgMjggYXZyLiAyMDE2IMOg
IDE2OjA1LCBKYWltZSBKaW3DqW5leiA8amFpbWUuamltZW5lekBlcmljc3Nvbi5jb20+IGEgw6lj
cml0IDoNCj4NCj4gSGkgYWxsLA0KPg0KPiBnb2luZyB0aHJvdWdoIHRoZSBpdGVtIGxpc3QsIGlu
IEJ1ZW5vcyBBaXJlcyB3ZSBkaXNjdXNzZWQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXZhbmRlcnN0
b2stY29yZS1ldGNoLTAwIGFzIFdHIGl0ZW0uIEJhY2sgdGhlbiB0aGVyZSB3YXMgcm9vbSBjb25z
ZW5zdXMgd2l0aCAxMiBwZW9wbGUgaW4gZmF2b3IgKCsgNCBtb3JlIG9uIHRoZSBqYWJiZXIpIGFu
ZCBub29uZSBhZ2FpbnN0Lg0KPg0KPiBUaGlzIHdvcmsgaXMgbmVlZGVkIGluIG9yZGVyIHRvIGtl
ZXAgdXNpbmcgUEFUQ0ggbGluayB1cGRhdGVzIG9uIHRoZSBSRCBhbmQgYWxzbyBmb3IgdGhlIENP
TUkgd29yayB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gYWRvcHRlZCBhcyBvZiB0aGlzIHdlZWsuDQo+
DQo+IFRoaXMgaXMgYSBvbmUtd2VlayBjYWxsIGZvciBjb25maXJtYXRpb24gb24gdGhhdCBkZWNp
c2lvbiwgc28gaWYgdGhlcmUgYXJlIG9iamVjdGlvbnMgcGxlYXNlIHZvaWNlIHRoZW0gb24gdGhl
IG1haWxpbmcgbGlzdCBieSAyMDE2LTA1LTA2Lg0KPg0KPiBDaWFvLA0KPiAtIC0gSmFpbWUgSmlt
ZW5leg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gVGhlIGNvbnRlbnRz
IG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3QgYmUgZGlzY2xvc2VkIHRvIG9yIHVz
ZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVu
ZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFz
ZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5k
IGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIg
bm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZp
cnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvciBvdGhlcndpc2Ug
Y2hlY2sgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4NCg==

--_000_VI1PR06MB1839420357E212CD42FDF6C6FC650VI1PR06MB1839eurp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg
LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl
ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+JiM0MzsxIGZvciB0aGUgc2FtZSByZWFz
b25zIE1pY2hlbCBoYXMuPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rp
dj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+
RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm
OyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmFAYWNrbC5pbyI+QWxleGFuZGVyIFBl
bG92PC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z
LXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw
dCI+4oCOMjgv4oCOMDQv4oCOMjAxNiAxNjo1MTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6
Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z
ZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpqYWltZS5qaW1lbmV6QGVyaWNz
c29uLmNvbSI+SmFpbWUgSmltw6luZXo8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpi
b2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl
cmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVA
aWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Og0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt
c2l6ZToxMXB0Ij5SZTogW2NvcmVdIPCflJQgV0cgYWRvcHRpb24gb2YgZHJhZnQtdmFuZGVyc3Rv
ay1jb3JlLWV0Y2gtMDA8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxmb250IHNp
emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5U
ZXh0Ij5EZWFyIGFsbCw8YnI+DQo8YnI+DQpJIGFtIGluIGZhdm9yIGZvciBhZG9wdGluZyB0aGUg
ZG9jdW1lbnQgYXMgYSBXRyBpdGVtLjxicj4NCjxicj4NCkJvdGggRkVUQ0ggYW5kIFBBVENIIGFy
ZSBhZGRpbmcgbWlzc2luZyBmdW5jdGlvbmFsaXR5IHRvIHRoZSBzZXQgb2Ygc3RhbmRhcmQgQ29B
UCB2ZXJicy4gVGhleSBwcm92aWRlIHNlbWFudGljcyB3aGljaCBhcmUgYWxyZWFkeSBwcmVzZW50
IGluIHN0YW5kYXJkIEhUVFAsIG9yIHRoYXQgd2lsbCBiZSBzdGFuZGFyZGl6ZWQgc29vbi48YnI+
DQo8YnI+DQpGb3Igbm9uLWNvbnN0cmFpbmVkIG5ldHdvcmtzIGFuZC9vciBkZXZpY2VzIHRoZWly
IGxhY2sgbWF5IGJlIGEgbWF0dGVyIG9mIHBlcnNvbmFsIGZlZWxpbmdzIG9yIHNsaWdodCBpbmNv
bnZlbmllbmNlcy4gRm9yIGNvbnN0cmFpbmVkIG5ldHdvcmtzIG9yIGNvbnN0cmFpbmVkIGRldmlj
ZXMsIHRoZWlyIGFkZGl0aW9uIHByb3ZpZGVzIHBvd2VyZnVsIG1ldGhvZHMgdG8gc2lnbmlmaWNh
bnRseSBsaW1pdCB0aGUgZGF0YSBzZW50IG9uIHRoZSBhaXIgJiM0MzsNCiBzaW1wbGlmeSB0aGUg
QVBJcy4gVGhlIGZ1bmN0aW9uYWxpdHkgcHJvdmlkZWQgYnkgRkVUQ0ggYW5kIFBBVENIIGNvdWxk
IGJlIHRvIHNvbWUgZXh0ZW50IGVtdWxhdGVkIHdpdGggUE9TVHMsIGJ1dCBtYW55IG9mIHRoZSBi
ZW5lZml0cyB3ZSBoYXZlIGZyb20gUkVTVGZ1bCBhcHBsaWNhdGlvbnMgYXJlIGxvc3QuDQo8YnI+
DQo8YnI+DQpUaHJvdWdoIHRoZSBkZXNpZ24gb2YgdGhlIGZ1bmN0aW9uIHNldCBvZiB0aGUgbGF0
ZXN0IENPTUkvQ09PTCBwcm9wb3NhbCwgd2XigJl2ZSBwYXNzZWQgdGhyb3VnaCBzZXZlcmFsIGl0
ZXJhdGlvbnMgYW5kIHdl4oCZdmUgaW52ZXN0aWdhdGVkIEZFVENIJiM0MztQQVRDSCBhcHByb2Fj
aCBWUyBuby1GRVRDSCBhbmQgbm8tUEFUQ0ggc29sdXRpb24uIFRoZSBsYXR0ZXIgcmVxdWlyZWQg
aW50cm9kdWNpbmcgbmV3IENvQVAgb3B0aW9uIGFuZCB3YXMgZ2VuZXJhbGx5DQogbW9yZSBjb21w
bGV4LiBTb21lIHRoaW5ncyB3ZXJlIHNpbXBseSBpbXBvc3NpYmxlIHdpdGhvdXQgdGhlIHVzZSBv
ZiBQT1NULjxicj4NCjxicj4NCk15IHBlcnNvbmFsIHRha2Ugb24gdGhpcyBpczogd2UgbmVlZCBG
RVRDSCBhbmQgUEFUQ0guIFRoZSB3b3JrIG9uIHRoZSBkb2N1bWVudCBhZHZhbmNlcyB2ZXJ5IHdl
bGwgYW5kIHRoZXJlIGFyZSBzZXZlcmFsIGtleSBwZW9wbGUgYWN0aXZlbHkgY29udHJpYnV0aW5n
IHRvIGl0Lg0KPGJyPg0KPGJyPg0KJiM0MzsxPGJyPg0KPGJyPg0KQmVzdCw8YnI+DQpBbGV4YW5k
ZXI8YnI+DQo8YnI+DQomZ3Q7IExlIDI4IGF2ci4gMjAxNiDDoCAxNjowNSwgSmFpbWUgSmltw6lu
ZXogJmx0O2phaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tJmd0OyBhIMOpY3JpdCA6PGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgZ29pbmcgdGhyb3VnaCB0
aGUgaXRlbSBsaXN0LCBpbiBCdWVub3MgQWlyZXMgd2UgZGlzY3Vzc2VkIHRoZSBhZG9wdGlvbiBv
ZiBkcmFmdC12YW5kZXJzdG9rLWNvcmUtZXRjaC0wMCBhcyBXRyBpdGVtLiBCYWNrIHRoZW4gdGhl
cmUgd2FzIHJvb20gY29uc2Vuc3VzIHdpdGggMTIgcGVvcGxlIGluIGZhdm9yICgmIzQzOyA0IG1v
cmUgb24gdGhlIGphYmJlcikgYW5kIG5vb25lIGFnYWluc3QuDQo8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgVGhpcyB3b3JrIGlzIG5lZWRlZCBpbiBvcmRlciB0byBrZWVwIHVzaW5nIFBBVENIIGxpbmsg
dXBkYXRlcyBvbiB0aGUgUkQgYW5kIGFsc28gZm9yIHRoZSBDT01JIHdvcmsgdGhhdCBoYXMgYWxy
ZWFkeSBiZWVuIGFkb3B0ZWQgYXMgb2YgdGhpcyB3ZWVrLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IFRoaXMgaXMgYSBvbmUtd2VlayBjYWxsIGZvciBjb25maXJtYXRpb24gb24gdGhhdCBkZWNpc2lv
biwgc28gaWYgdGhlcmUgYXJlIG9iamVjdGlvbnMgcGxlYXNlIHZvaWNlIHRoZW0gb24gdGhlIG1h
aWxpbmcgbGlzdCBieSAyMDE2LTA1LTA2Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBDaWFvLDxicj4N
CiZndDsgLSAtIEphaW1lIEppbWVuZXo8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGNvcmUgbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OyBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vY29yZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0K
Y29yZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3Jl
PC9hPjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1h
aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQuIFRoZXkgbWF5IG5vdCBiZSBkaXNjbG9zZWQgdG8gb3IgdXNlZCBieSBvciBjb3Bp
ZWQgaW4gYW55IHdheSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQNCiByZWNpcGll
bnQuIElmIHRoaXMgZS1tYWlsIGlzIHJlY2VpdmVkIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl
bHkgbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhdHRhY2hlZCBk
b2N1bWVudHMuIFBsZWFzZSBub3RlIHRoYXQgbmVpdGhlciB0aGUgc2VuZGVyIG5vciB0aGUgc2Vu
ZGVyJ3MgY29tcGFueSBhY2NlcHQgYW55IHJlc3BvbnNpYmlsaXR5IGZvciB2aXJ1c2VzIGFuZCBp
dCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5DQogdG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhp
cyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cy4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_VI1PR06MB1839420357E212CD42FDF6C6FC650VI1PR06MB1839eurp_--


From nobody Thu Apr 28 13:30:47 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DFA12B04A for ; Thu, 28 Apr 2016 13:30:44 -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] 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 T6C85wNe0rPQ for ; Thu, 28 Apr 2016 13:30:42 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B7D12B033 for ; Thu, 28 Apr 2016 13:30:42 -0700 (PDT)
Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 77B7141C08B; Thu, 28 Apr 2016 22:30:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id hOqM4dvfGCUj; Thu, 28 Apr 2016 22:30:38 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6529F41C089; Thu, 28 Apr 2016 22:30:38 +0200 (CEST)
Message-ID: <572272EF.2020805@tzi.org>
Date: Thu, 28 Apr 2016 22:30:39 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "core@ietf.org WG" 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [core] Draft minutes for CoRE@IETF95
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2016 20:30:44 -0000

Jaime and I have uploaded the draft minutes for Buenos Aires:
https://www.ietf.org/proceedings/95/minutes/minutes-95-core

Please send comments/corrections to the chairs or to the list, before
May 23rd.

Grüße, Carsten


From nobody Fri Apr 29 03:47:36 2016
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 EC04712D095; Fri, 29 Apr 2016 03:47:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160429104734.12489.47604.idtracker@ietfa.amsl.com>
Date: Fri, 29 Apr 2016 03:47:34 -0700
Archived-At: 
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-block-20.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 10:47:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : Block-wise transfers in CoAP
        Authors         : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-20.txt
	Pages           : 34
	Date            : 2016-04-29

Abstract:
   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  Basic CoAP messages work well for the small payloads we
   expect from temperature sensors, light switches, and similar
   building-automation devices.  Occasionally, however, applications
   will need to transfer larger payloads -- for instance, for firmware
   updates.  With HTTP, TCP does the grunt work of slicing large
   payloads up into multiple packets and ensuring that they all arrive
   and are handled in the right order.

   CoAP is based on datagram transports such as UDP or DTLS, which
   limits the maximum size of resource representations that can be
   transferred without too much fragmentation.  Although UDP supports
   larger payloads through IP fragmentation, it is limited to 64 KiB
   and, more importantly, doesn't really work well for constrained
   applications and networks.

   Instead of relying on IP fragmentation, this specification extends
   basic CoAP with a pair of "Block" options, for transferring multiple
   blocks of information from a resource representation in multiple
   request-response pairs.  In many important cases, the Block options
   enable a server to be truly stateless: the server can handle each
   block transfer separately, with no need for a connection setup or
   other server-side memory of previous block transfers.

   In summary, the Block options provide a minimal way to transfer
   larger representations in a block-wise fashion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-block-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20


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

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


From nobody Fri Apr 29 03:51:48 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360D812D5FE for ; Fri, 29 Apr 2016 03:51:47 -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] 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 H1_jJ4qE8IVx for ; Fri, 29 Apr 2016 03:51:45 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F364212D095 for ; Fri, 29 Apr 2016 03:51:44 -0700 (PDT)
Received: from mfilter45-d.gandi.net (mfilter45-d.gandi.net [217.70.178.176]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 7456D1720BF; Fri, 29 Apr 2016 12:51:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter45-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter45-d.gandi.net (mfilter45-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id bYjZT9JQ3Meq; Fri, 29 Apr 2016 12:51:41 +0200 (CEST)
X-Originating-IP: 134.102.164.196
Received: from nar-3.local (unknown [134.102.164.196]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2DA6E1720F3; Fri, 29 Apr 2016 12:51:41 +0200 (CEST)
Message-ID: <57233CBB.4060101@tzi.org>
Date: Fri, 29 Apr 2016 12:51:39 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: core@ietf.org
References: <20160429104734.12489.47604.idtracker@ietfa.amsl.com>
In-Reply-To: <20160429104734.12489.47604.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [core] I-D Action: draft-ietf-core-block-20.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 10:51:47 -0000

This update contains changes that address the IESG DISCUSS and COMMENT
ballots.

This SHOULD all be editorial in nature, but please do have a look
whether I unintentionally changed anything substantive.
(Note that we continue to be in IESG processing, so we are mainly
addressing IESG comments, but if you find anything that is broken, we
need to know before the RFC is published.)

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Grüße, Carsten


internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Constrained RESTful Environments of the IETF.
> 
>         Title           : Block-wise transfers in CoAP
>         Authors         : Carsten Bormann
>                           Zach Shelby
> 	Filename        : draft-ietf-core-block-20.txt
> 	Pages           : 34
> 	Date            : 2016-04-29
> 
> Abstract:
>    CoAP is a RESTful transfer protocol for constrained nodes and
>    networks.  Basic CoAP messages work well for the small payloads we
>    expect from temperature sensors, light switches, and similar
>    building-automation devices.  Occasionally, however, applications
>    will need to transfer larger payloads -- for instance, for firmware
>    updates.  With HTTP, TCP does the grunt work of slicing large
>    payloads up into multiple packets and ensuring that they all arrive
>    and are handled in the right order.
> 
>    CoAP is based on datagram transports such as UDP or DTLS, which
>    limits the maximum size of resource representations that can be
>    transferred without too much fragmentation.  Although UDP supports
>    larger payloads through IP fragmentation, it is limited to 64 KiB
>    and, more importantly, doesn't really work well for constrained
>    applications and networks.
> 
>    Instead of relying on IP fragmentation, this specification extends
>    basic CoAP with a pair of "Block" options, for transferring multiple
>    blocks of information from a resource representation in multiple
>    request-response pairs.  In many important cases, the Block options
>    enable a server to be truly stateless: the server can handle each
>    block transfer separately, with no need for a connection setup or
>    other server-side memory of previous block transfers.
> 
>    In summary, the Block options provide a minimal way to transfer
>    larger representations in a block-wise fashion.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-block/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-core-block-20
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 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
> 


From nobody Fri Apr 29 06:25:22 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCF412D684; Fri, 29 Apr 2016 06:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.896
X-Spam-Level: 
X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 MgToTnZ8a8yW; Fri, 29 Apr 2016 06:25:19 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 56A6D12D098; Fri, 29 Apr 2016 06:25:16 -0700 (PDT)
Received: from localhost ([::1]:34668 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aw8Pz-0005vH-TS; Fri, 29 Apr 2016 06:25:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "core issue tracker" 
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-core-senml@ietf.org, ari.keranen@ericsson.com
X-Trac-Project: core
Date: Fri, 29 Apr 2016 13:25:15 -0000
X-URL: https://tools.ietf.org/core/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/core/trac/ticket/407
Message-ID: <064.66056f64a3dd3faf69992ec5f1eba532@trac.tools.ietf.org>
X-Trac-Ticket-ID: 407
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-senml@ietf.org, ari.keranen@ericsson.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-core-senml@ietf.org
Resent-Message-Id: <20160429132519.56A6D12D098@ietfa.amsl.com>
Resent-Date: Fri, 29 Apr 2016 06:25:16 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Archived-At: 
Cc: core@ietf.org
Subject: [core]  #407 (senml): SenML extensions and label registry
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: trac+core@zinfandel.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 13:25:21 -0000

#407: SenML extensions and label registry

 Describe what kind of extensions to SenML are possible (new units, base
 values, etc.) and how to do them. Also specify details of SenML label
 registry.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-core-
  ari.keranen@ericsson.com           |  senml@ietf.org
     Type:  task                     |     Status:  new
 Priority:  major                    |  Milestone:
Component:  senml                    |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
core 


From nobody Fri Apr 29 11:36:08 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5512D6AF; Fri, 29 Apr 2016 11:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 yE5T5aL5p9AC; Fri, 29 Apr 2016 11:36:05 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9F412D70B; Fri, 29 Apr 2016 11:36:03 -0700 (PDT)
Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 020B3C5A5A; Fri, 29 Apr 2016 20:36:02 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 5tV4QcQVFWu8; Fri, 29 Apr 2016 20:35:59 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 4CAD2C5A70; Fri, 29 Apr 2016 20:35:58 +0200 (CEST)
Message-ID: <5723A98D.2060001@tzi.org>
Date: Fri, 29 Apr 2016 20:35:57 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "Mirja Kuehlewind (IETF)" 
References: <20160420110510.32319.55772.idtracker@ietfa.amsl.com> <57187ABB.7050301@tzi.org> <27FCC29F-4D67-4703-B5FD-DC77F4789634@kuehlewind.net>
In-Reply-To: <27FCC29F-4D67-4703-B5FD-DC77F4789634@kuehlewind.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org
Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-c?= =?utf-8?q?ore-block-19=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 18:36:07 -0000

Hi Mirja,

I believe I have addressed your DISCUSS and COMMENTs in
draft-ietf-core-block-20.

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Specifically:

>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> This is only a minor point, requesting to spell out implicit assumptions
>>> explicitly. However, I think it's important to address this before
>>> publication.
>>>
>>> It is not clear in the main part of the doc that this extension to does
>>> not change the message transmission method as specified in RFC7252
>>> (Stop-and-wait retransmission). With my initial ready I assumed that this
>>> extension would allow the sending of back-to-back messages. Only by
>>> looking at the examples, it got clear to me that this is not the case. 
>> I'm wondering how we managed to create that expectation.
> 
> I guess by not talking about it at all (and Spencer and me being overly sensitive to this topic) :-)
> 
>> As I said in the response to Spencer's comment, block-wise transfers are
>> strictly layered on top of RFC 7252 CoAP.  Maybe there is some
>> introductory text needed that emphasizes this early on.
> 
> Yes, please add something similar as what you’ve written in your response to Spencer, (early) in the doc. Thanks!
> 
>> Implementations that I know run completely lock-step.  Theoretically, an
>> implementation could pipeline requests for further blocks after the
>> initial exchange (which needs to be lock-step so a common block-size can
>> be determined; also, a Size2 option would be needed to determine the
>> number of requests to be sent).  NSTART (Section 4.7 of RFC 7252) puts a
>> hard limit on the parallelism here, and the default value of NSTART
>> (without advanced congestion control) is 1, so we are back to lock-step.
> 
> Okay, the problem with not talking about this at all is that all these value in rfc7252 are only recommendation. There are no restricting max values which are defined like 'MUST NOT be larger than X'. Therefore my fear would be that people could assume that this extension, as it supports sending or larger data, could provide a reason to increase the default values.
> 
> Would it make sense to say something like: Using this extension MUST NOT lead to changes in the transmission behavior (e.g. other default value than specified in RFC7252).  ?
> 
>>> Further, this document does not say anything about reliability. Do block
>>> message need to be transmitted reliable (as Confirmable)? If not, this
>>> extension could still lead to back-to-back sending and then further
>>> guidance on congestion control would be needed.
>> Block-wise transfers can be sent in NON messages.  That would not be a
>> particularly wise choice in general, as the delivery probability for the
>> whole body decreases exponentially (section 2.8 outlines one specific
>> use case for using NON in the first block only, though).
> 
> Again, I don’t think this is spelled to anywhere and really should.
> 
>> NON messages can not simply be sent back-to-back in CoAP, see section
>> 4.7 of RFC 7252.
> 
> Please correct me if I’m wrong but looking at section 4.7 this might not be well enough defined to be fully applicable and save for a case where you send a large message with several blocks as NON (even though this is in general not recommended). Note, 4.7 is explicitly saying "Further congestion control optimizations and considerations are expected in the future“. Please double-check and consider giving further recommendations in this doc!

All this should be addressed by the new paragraph right in the introduction.

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I agree with others that reduncy makes the doc harder to read, especially
>>> regarding SHOULDs and MUSTs. Would it be helpful to have all SHOULDs and
>>> MUST in one section and combine the Usage guidance with the examples?
>> The usage guidance (section 2.5?) is more normative than just an
>> example.  Moving all interoperability requirements into one section
>> might create even more duplication of text.
> 
> Might still be worth trying to remove redundancy where possible and double-check all MUST and SHOULD. Thanks!

Ben identified a particularly atrocious use of SHOULD in Section 2.4, I
have fixed that.  Apart from that, I tried to refrain from major surgery
-- this document has been around for a while, been tested in four
plugtests, etc.  Risks vs. benefit.

>>> Further, please also add a reference for ETag in section 2.4.
>> I have added a reference to Section 5.10.6 of RFC 7252 in the editor's
>> draft.

Done.

Grüße, Carsten


From nobody Fri Apr 29 12:03:20 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DBF12D6E6; Fri, 29 Apr 2016 12:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er6bQR0KIaLG; Fri, 29 Apr 2016 12:03:17 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F9812D1DA; Fri, 29 Apr 2016 12:03:17 -0700 (PDT)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id BEB36FB89F; Fri, 29 Apr 2016 21:03:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id OYLi_OEa5RDs; Fri, 29 Apr 2016 21:03:13 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 62AC0FB8A3; Fri, 29 Apr 2016 21:03:11 +0200 (CEST)
Message-ID: <5723AFEE.3060608@tzi.org>
Date: Fri, 29 Apr 2016 21:03:10 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Ben Campbell 
References: <20160421140904.19594.51871.idtracker@ietfa.amsl.com>
In-Reply-To: <20160421140904.19594.51871.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , core@ietf.org
Subject: Re: [core] Ben Campbell's No Objection on draft-ietf-core-block-19: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 19:03:19 -0000

Hi Ben,

your COMMENTs should be addressed in draft-ietf-core-block-20

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I moved the following from a DISCUSS to a COMMENT, pending the next
> revision:
> 
> -- START:
> This should be easy to clean up, and it's entirely possible I am
> misreading something. But Section 3.4, 2nd and 3rd paragraph seem to be
> inconsistent in SHOULD vs MUST for block size.  I _think_ I'm reading the
> following:
> 
> 1. If the client requests a specific block size, the server MUST use that
> size or a smaller one. 
> 
> 2. Any subsequent requests from the client MUST indicate the same size
> that the server used
> 
> 3. But paragraph 3 then says all further requests SHOULD indicate the
> same size. But if they already MUST indicate the same size as in the
> initial response, then this   SHOULD seems non-constraining at best, and
> at worst in conflict with 1. (ignoring the last-block size issue for the
> moment.)
> 
> 4. Then paragraph 3 goes on to say the server SHOULD use the block size
> indicated in the request or smaller. This seems to conflict with the MUST
> in 1.
> 
> 5.  Then it again asserts that the client MUST indicate the same size in
> subsequent requests, conflicting with the SHOULD in 3., but agreeing with
> the MUST in 1.
> 
> -- END

The two SHOULDs are now plain text describing the outcome, not the
behavior of each peer.  (See the changes on what is now page 11.)

> Substantive:
> 
> - General: The draft dives into detail without giving much context until
> the examples. The reader is left to infer the forest from the trees. It
> would be very helpful (to me, at least) to add a high-level overview of
> operation early in the document, including definitions for "descriptive"
> vs " control" usages. (I know it's late in the process to ask for a whole
> new section, so I won't push the point.)

Here, the risk of creating new problems needs to be weighted against the
convenience for new readers.  As I told Mirja, I refrained from major
surgery.

> - The distinction between the option names Block1 and Block2 seems almost
> actively non-mnemonic. Is that intentional? (I won't push this point,
> either.)

(It is quite mnemonic after a while, and it is less confusing than other
alternatives we have discussed.)

> - 3.4: Does the eTag apply to the "payload" or the whole "body"?

Reinforced by new text in the intro to section 2 (page 5).

> - 2.5, 2nd paragraph, last sentence:
> Should I read this to mean that the reduction in block size is
> retroactive? That could use some elaboration. (I thought I read comments
> in the examples suggesting such a reduction would _not_ be retroactive).

I'm still not sure how to address this.

> - 7: Does "object security" apply to the "payload", or the "body"?
> Can you describe or add a reference for the "usual considerations"?

(See my previous comments.)

> Editorial:
> 
> - Abstract: That’s a really long abstract, and serves more as an
> introduction than an abstract. Please consider combining the first and
> last paragraph and leaving the rest to the introduction.

(See my previous comments.)

> - 2.4, paragraph 5: a definition for "reassembler" would be helpful.

(Entirely removed the term instead, page 11.)

> - Figures 5 and 6:
> There's no discussion of either figure. Is that intentional?

(As discussed)

Grüße, Carsten


From nobody Fri Apr 29 12:06:55 2016
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115CC12D728; Fri, 29 Apr 2016 12:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 T0oy3I4W8FBV; Fri, 29 Apr 2016 12:06:51 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7E212D724; Fri, 29 Apr 2016 12:06:51 -0700 (PDT)
Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id D3B2B41C088; Fri, 29 Apr 2016 21:06:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter36-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id arRV_dgOqqLM; Fri, 29 Apr 2016 21:06:48 +0200 (CEST)
X-Originating-IP: 93.199.242.26
Received: from nar-3.local (p5DC7F21A.dip0.t-ipconnect.de [93.199.242.26]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6869D41C07D; Fri, 29 Apr 2016 21:06:45 +0200 (CEST)
Message-ID: <5723B0C4.7020601@tzi.org>
Date: Fri, 29 Apr 2016 21:06:44 +0200
From: Carsten Bormann 
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Spencer Dawkins at IETF 
References: <20160418044805.28780.94432.idtracker@ietfa.amsl.com> <571864D3.2000906@tzi.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, The IESG , "core@ietf.org" 
Subject: Re: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 19:06:54 -0000

Hi Spencer,

I think I have addressed your comments in draft-ietf-core-block-20

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Specifically:

> My problem was that I didn't understand from the text that the same
> method of pacing packets that contained complete requests was being used
> to pace packets that contained blocks. I think that I can derive what
> you're saying from the draft, but it wasn't clear to me.
> 
> I saw that in the thread of Mirja's Discuss, you suggested adding this
> point more explicitly. That would solve my issue here.

See the new text in the introduction.

>  
> 
>     > I'm reading this text,
>     >
>     >    In most cases, all blocks being transferred for a body (except for
>     >    the last one) will be of the same size.
>     >
>     > and then this text
>     >
>     >       *  The block size implied by SZX MUST match the size of the
>     >          payload in bytes, if the M bit is set.  (SZX does not govern
>     >          the payload size if M is unset).  For Block2, if the request
>     >          suggested a larger value of SZX, the next request MUST
>     move SZX
>     >          down to the size given in the response.  (The effect is that,
>     >          if the server uses the smaller of (1) its preferred block size
>     >          and (2) the block size requested, all blocks for a body
>     use the
>     >          same block size.)
>     >
>     > and realizing that I'm confused about why all the blocks for a body
>     might
>     > NOT use the same block size. Maybe this doesn't matter (because an
>     > implementation would need to be prepared for the case when all the
>     blocks
>     > don't use the same block size)?
> 
>     The first request may be using a block size that is larger than what the
>     server prefers.  That is one case where the block size changes during a
>     whole transfer.  See also Figure 4 for an example where the client
>     prefers a smaller block size than the server sent initially.
> 
>     So, yes, an implementation needs to be prepared for cases where at least
>     the initial block is of a different size than the following (full)
>     blocks.  I believe this is evident to the implementers at least from the
>     examples.
> 
> 
> That's very helpful. 
> 
> Would it be correct to say (in the first paragraph I included above)
> something like
> 
>     In most cases, all blocks being transferred for a body (except for
>     the last one) will be of the same size. If the first request uses a
> bigger
>     block size than the receiver prefers, subsequent requests will use
>     the preferred block size.
> 
> just so you're not relying on implementers to figure out what to
> implement solely from the examples?

Thanks for the text suggestion.  That text is now in the last paragraph
of the introduction to section 2.

Grüße, Carsten


From nobody Sat Apr 30 11:33:08 2016
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 CD49112B00C; Sat, 30 Apr 2016 11:33:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160430183305.31173.14908.idtracker@ietfa.amsl.com>
Date: Sat, 30 Apr 2016 11:33:05 -0700
Archived-At: 
Cc: core@ietf.org
Subject: [core] I-D Action: draft-ietf-core-yang-cbor-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Apr 2016 18:33:06 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : CBOR Encoding of Data Modeled with YANG
        Authors         : Michel Veillette
                          Alexander Pelov
                          Abhinav Somaraju
                          Randy Turner
                          Ana Minaburo
	Filename        : draft-ietf-core-yang-cbor-00.txt
	Pages           : 31
	Date            : 2016-04-28

Abstract:
   This document defines encoding rules for serializing configuration
   data, state data, RPC input and RPC output, Action input, Action
   output and notifications defined within YANG modules using the
   Concise Binary Object Representation (CBOR) [RFC7049].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-yang-cbor-00


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

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