From nobody Sun Nov 1 13:13:42 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3A1A0271 for ; Mon, 26 Oct 2015 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHgTxCp-BFFp for ; Mon, 26 Oct 2015 13:29:23 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.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 178611A0270 for ; Mon, 26 Oct 2015 13:29:22 -0700 (PDT) Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-31-QKeUCplATN2f31klpyZPWQ-1; Mon, 26 Oct 2015 20:29:20 +0000 Received: from GB-CAM-EXCAS1.Emea.Arm.com (10.1.105.66) by emea-cam-gw1.Emea.Arm.com (10.1.248.203) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 26 Oct 2015 20:29:20 +0000 Received: from emea01-am1-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.105.66) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 26 Oct 2015 20:29:20 +0000 Received: from HE1PR08MB0810.eurprd08.prod.outlook.com (10.164.52.156) by HE1PR08MB0809.eurprd08.prod.outlook.com (10.164.52.155) with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 20:29:18 +0000 Received: from HE1PR08MB0810.eurprd08.prod.outlook.com ([10.164.52.156]) by HE1PR08MB0810.eurprd08.prod.outlook.com ([10.164.52.156]) with mapi id 15.01.0306.003; Mon, 26 Oct 2015 20:29:18 +0000 From: Michael Koster To: Core Thread-Topic: New Version Notification for draft-ietf-core-interfaces-04.txt Thread-Index: AQHRCsLV2xxSRYQvH0S+P3Gyiv4tjJ59zxYA Date: Mon, 26 Oct 2015 20:29:18 +0000 Message-ID: References: <20151019230639.19755.78387.idtracker@ietfa.amsl.com> In-Reply-To: <20151019230639.19755.78387.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [108.201.184.41] x-microsoft-exchange-diagnostics: 1; HE1PR08MB0809; 5:g3pPw2JLuBUlqcLD3H5TJ5vx2jntuKqaCmjBR0VPg5lmk50C0tBRfXWcVrrF7aHNX1xinETX5yJBUN3T1+lt6Sh3H/d665BIPkbGXhELrKj4LUxLIcFk0E87MuXKuQA6ez3mt0erI66lsNHX7Q65nw==; 24:9cu/fnB20uRUMCzESqbymHfw0JKy3MgDOukktHW9OBXD1a3LbaY70qL8N3FgqRmge2A1CAKWh+Q5wb6dwgVha6YiPlwhqT2sfQZ9isKnT3w=; 20:C7uvJuIqPu7/q6b5g0CZ2a35D/jUEFgx3t4uozY3pTT7Fe/N0j595Igopiygfd6uG6PJebY/+7DAizoB9afrUM6jJBGBWdsubPuKwf1kUYMVMUjRouu6UjNazH6Tkta12sRa7e3F/P1zXkvP9NUv+RERN4SoOifyG26dIFwpC5E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0809; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:HE1PR08MB0809; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0809; x-forefront-prvs: 0741C77572 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(377424004)(377454003)(479174004)(24454002)(54356999)(105586002)(83506001)(11100500001)(122556002)(10400500002)(36756003)(76176999)(4001150100001)(5007970100001)(101416001)(107886002)(5004730100002)(77096005)(4001350100001)(50986999)(81156007)(189998001)(97736004)(450100001)(110136002)(2950100001)(2900100001)(5002640100001)(230783001)(5001960100002)(40100003)(15975445007)(102836002)(92566002)(106116001)(106356001)(19580395003)(19580405001)(87936001)(66066001)(86362001)(5008740100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0809; H:HE1PR08MB0810.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-ID: <515E808AEF3AFB4EAC25C1430B3853C2@eurprd08.prod.outlook.com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2015 20:29:18.0150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0809 X-OriginatorOrg: arm.com X-MC-Unique: QKeUCplATN2f31klpyZPWQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 13:13:41 -0800 Subject: [core] FW: New Version Notification for draft-ietf-core-interfaces-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 20:29:25 -0000 Hi, This version is substantially updated from the earlier version, to focus on the interface definitions that make up the bulk of the document. There is a new Hypermedia Collection type that enables resources to be organized in many different ways using RFC6690 web linking and link embedding. This collection type extends the functionality of the link list, batch, and linked batch collection types, and adds resource grouping, dynamic creation of items, and link patching. Some outstanding tickets are resolved, and some things are clarified and updated. Please review and comment. Best regards, Michael On 10/19/15, 4:06 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-core-interfaces-04.txt >has been successfully submitted by Michael Koster and posted to the >IETF repository. > >Name: draft-ietf-core-interfaces >Revision: 04 >Title: Reusable Interface Definitions for Constrained RESTful >Environments >Document date: 2015-10-19 >Group: core >Pages: 36 >URL: >https://www.ietf.org/internet-drafts/draft-ietf-core-interfaces-04.txt >Status: >https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ >Htmlized: https://tools.ietf.org/html/draft-ietf-core-interfaces-04 >Diff: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-interfaces-04 > >Abstract: > This document defines a set of reusable REST resource design patterns > suitable for use in constrained environments, based on IETF CoRE > standards for information representation and information exchange. > > Interface types for Sensors, Actuators, Parameters, and resource > Collections are defined using the "if" link attribute defined by CoRE > Link Format [RFC6690]. Clients may use the "if" attribute to > determine how to consume resources. > > Dynamic linking of state updates between resources, either on an > endpoint or between endpoints, is defined with the concept of Link > Bindings. We also define conditional observation attributes that > work with Link Bindings or with simple CoAP Observe [RFC7641]. > > > > > >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 > ________________________________ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. From nobody Sun Nov 1 17:15:58 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180B81B3F42; Sun, 1 Nov 2015 17:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.047 X-Spam-Level: X-Spam-Status: No, score=0.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_06_12=1.947] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztVu71WBwqH2; Sun, 1 Nov 2015 17:15:55 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560501B3F40; Sun, 1 Nov 2015 17:15:55 -0800 (PST) Received: from dhcp-52-42.meeting.ietf94.jp (t20010c400000304829f94d48d386f890.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3048:29f9:4d48:d386:f890]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id EACC8172067; Mon, 2 Nov 2015 02:15:50 +0100 (CET) To: core@ietf.org, 6tisch@ietf.org From: Alexander Pelov Message-ID: <563729CD.30701@ackl.io> Date: Mon, 2 Nov 2015 10:15:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] CoOL initial version - management interface for constrained devices and networks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:15:57 -0000 Dear all, In preparation for the presentation this Friday in CORE you can find the first version of the CoOL (Constrained Objects Language) draft at the following address: https://datatracker.ietf.org/doc/draft-veillette-core-cool/ Best, Alexander From nobody Sun Nov 1 17:21:50 2015 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 851EE1B3FA6; Sun, 1 Nov 2015 17:21:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102012147.9680.84653.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 17:21:47 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-links-json-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:21:47 -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 Working Group of the IETF. Title : Representing CoRE Formats in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-04.txt Pages : 18 Date : 2015-11-01 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-04 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 Sun Nov 1 17:32:39 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3216A1ACE57 for ; Sun, 1 Nov 2015 17:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUSp7DUzbDrT for ; Sun, 1 Nov 2015 17:32:33 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59BB1ACE3E for ; Sun, 1 Nov 2015 17:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tA21WN1k015991; Mon, 2 Nov 2015 02:32:23 +0100 (CET) Received: from dhcp-38-127.meeting.ietf94.jp (t20010c4000003032cc8f9d73cbb98481.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:cc8f:9d73:cbb9:8481]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3npxYy2Tx4z2FRD; Mon, 2 Nov 2015 02:32:22 +0100 (CET) Message-ID: <5636BD20.1020804@tzi.org> Date: Mon, 02 Nov 2015 10:32:16 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) MIME-Version: 1.0 To: "core@ietf.org WG" References: <20151102012147.9680.61904.idtracker@ietfa.amsl.com> In-Reply-To: <20151102012147.9680.61904.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] New Version Notification for draft-ietf-core-links-json-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:32:34 -0000 Apart from the usual updates in the references, this new version just adds integers for the attribute names defined by the CoRE resource directory. > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-04 Gr眉脽e, Carsten internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-core-links-json-04.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. > > Name: draft-ietf-core-links-json > Revision: 04 > Title: Representing CoRE Formats in JSON and CBOR > Document date: 2015-11-01 > Group: core > Pages: 18 > URL: https://www.ietf.org/internet-drafts/draft-ietf-core-links-json-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ > Htmlized: https://tools.ietf.org/html/draft-ietf-core-links-json-04 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-04 > > 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. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > From nobody Sun Nov 1 19:38:46 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9700F1ACEEA for ; Sun, 1 Nov 2015 19:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcxqKS3SZZYx for ; Sun, 1 Nov 2015 19:38:40 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id E87901ACEE4 for ; Sun, 1 Nov 2015 19:38:39 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id BBE1E19FCC0 for ; Mon, 2 Nov 2015 11:38:38 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.240.137]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7739919FCB3; Mon, 2 Nov 2015 11:38:37 +0800 (HKT) Message-ID: <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC> From: "weigengyu" To: "Rahman, Akbar" , "Abhijan Bhattacharyya" , , , References: <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com> In-Reply-To: <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com> Date: Mon, 2 Nov 2015 11:38:37 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01D11563.0360B4B0" 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: Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 03:38:44 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0086_01D11563.0360B4B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Abhijan, one question, > 2. Option Definition > Using this option with CON type of requests may not have any significance if piggybacked responses are triggered. But, in case the server responds with a separate response (which, may be, the client does not care about) then this option can be useful. Suppressing the separate response reduces one additional traffic in this case. The No-reponse option is about request and response layer semantics.=20 When No-response option works, why the piggybacked responses are = triggered unless No-response is not recognized.=20 If the No-Response option works, it would stop the response whether it = is the piggybacked or the separated.=20 It is uncleatr why it is different between the piggybacked and the = separate. When the receive ignore the No-Response option, it can response by = piggybacked or separated way.=20 Why does the draft suppose just to suppress the separate response? =20 And when the No-Response works, the ACK of CON may contain an empty = response.=20 The following process of the sender side is the same as definitions for = suppressing separate response. =20 The CON/ACK is about the message layer semantics.=20 It seems that the No-reponse does not touch the message layer semantics. = Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Rahman, Akbar=20 Sent: Sunday, October 18, 2015 8:17 AM To: Abhijan Bhattacharyya ; esko.dijk@philips.com ; cabo@tzi.org ; = core@ietf.org=20 Subject: Re: [core] New Version Notification for = draft-tcs-coap-no-response-option-12.txt >Akbar, The reverse proxy consideration have been included as a new = section 4.3. =20 Thanks, Abhijan. Looks good. =20 =20 =20 One other question, why does the draft say =E2=80=9CExpired=E2=80=9D at = the top even though the expiry date is April 2016? =20 https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 =20 =20 =20 From: Abhijan Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20 Sent: Thursday, October 15, 2015 9:23 AM To: esko.dijk@philips.com; cabo@tzi.org; core@ietf.org; Rahman, Akbar = Subject: Fw: New Version Notification for = draft-tcs-coap-no-response-option-12.txt =20 Hi Carsten, Esko, Akbar and all,=20 Based on the recent inputs we have shared a new version of the = No-Response draft.=20 Esko, I have actually removed the 'Leisure' stuff for unicast. Thought = it was making things a bit complicated.=20 Akbar, The reverse proxy consideration have been included as a new = section 4.3.=20 Carsten, requesting your suggestion regarding the next step forward.=20 Hoping to see you all in Yokohama.=20 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 10/15/2015 06:45 PM = -----=20 From: internet-drafts@ietf.org=20 To: "Soma Bandyopadhyay" , "Soma = Bandyopadhyay" , "Abhijan Bhattacharyya" = , "Arpan Pal" , "Arpan = Pal" , "Tulika Bose" , "Abhijan = Bhattacharyya" , "Tulika Bose" = =20 Date: 10/15/2015 06:45 PM=20 Subject: New Version Notification for = draft-tcs-coap-no-response-option-12.txt=20 -------------------------------------------------------------------------= ------- A new version of I-D, draft-tcs-coap-no-response-option-12.txt has been successfully submitted by Tulika Bose and posted to the IETF repository. Name: draft-tcs-coap-no-response-option Revision: 12 Title: CoAP option for no = server-response Document date: 2015-10-15 Group: Individual Submission Pages: 17 URL: = https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-option-12= .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-12 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-12 Abstract: There can be M2M scenarios where responses from server against requests from client might be considered 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 simultaneously updating a bulk of resources or updating a resource with a very high frequency. CoAP already provides a non-confirmable (NON) mode of message exchange where the server end-point does not respond with ACK. However, obeying the request/response semantics, the server end-point responds back with a status code indicating "the result of the attempt to understand and satisfy the request". This draft introduces a header option for CoAP called 'No-Response'. Using this option the client explicitly tells the server to suppress responses against the particular request. This option also provides granular control to enable suppression of a particular class or a combination of response-classes. This option may be effective for both unicast and multicast requests. Present draft also discusses few exemplary applications which benefit from this option. = =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. The IETF Secretariat =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain=20 confidential or privileged information. If you are=20 not the intended recipient, any dissemination, use,=20 review, distribution, printing or copying of the=20 information contained in this e-mail message=20 and/or attachments to it are strictly prohibited. If=20 you have received this communication in error,=20 please notify us by reply e-mail or telephone and=20 immediately and permanently delete the message=20 and any attachments. Thank you -------------------------------------------------------------------------= ------- _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0086_01D11563.0360B4B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Abhijan,
 
one question,
 
> 2. Option Definition
> Using this option with CON type of requests may not have = any
      significance if piggybacked = responses are=20 triggered. But, in case
      the server responds with a separate = response=20 (which, may be, the
      client does not care about) then = this option=20 can be useful.
      Suppressing the separate response = reduces=20 one additional traffic
      in this case.
 
The No-reponse option is about request and response layer = semantics.
When No-response option works, why the piggybacked responses are = triggered=20 unless No-response is not recognized.
If the=20 No-Response option works, it would stop the response whether it is the=20 piggybacked or the separated.
It is=20 uncleatr why it is different between the piggybacked and the = separate.
 
When the=20 receive ignore the No-Response option, it can response by piggybacked or = separated way.
Why does=20 the draft suppose just to suppress the separate = response?   =20
 
And when=20 the No-Response works, the ACK of CON may contain an empty response. =
The=20 following process of the sender side is the same as definitions for = suppressing=20 separate response. 
 
The CON/ACK=20 is about the message layer semantics.
It seems=20 that the No-reponse does not touch the message layer semantics.
  Regards,  
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Rahman, Akbar
Sent: Sunday, October 18, 2015 8:17 AM
To: Abhijan Bhattacharyya = ; esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org =
Subject: Re: [core] New Version Notification for=20 draft-tcs-coap-no-response-option-12.txt
 

>Akbar, = The reverse=20 proxy consideration have been included as a new section 4.3.

 

Thanks,=20 Abhijan.  Looks good.

 

 

 

One=20 other question, why does the draft say =E2=80=9CExpired=E2=80=9D at the = top  even though=20 the expiry date is April 2016?

 

https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12

 

 

 

From: Abhijan=20 Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]
Sent: = Thursday,=20 October 15, 2015 9:23 AM
To: esko.dijk@philips.com; = cabo@tzi.org;=20 core@ietf.org; Rahman, Akbar=20 <Akbar.Rahman@InterDigital.com>
Subject: Fw: New Version = Notification for = draft-tcs-coap-no-response-option-12.txt

 

Hi Carsten, = Esko, Akbar=20 and all,

Based on the = recent=20 inputs we have shared a new version of the No-Response draft.=20

Esko, I=20 have actually removed the 'Leisure' stuff for unicast. Thought it was = making=20 things a bit complicated.

Akbar, The = reverse=20 proxy consideration have been included as a new section 4.3.=20

Carsten,=20 requesting your suggestion regarding the next step forward. =

Hoping to see = you all=20 in Yokohama.

Regards
Abhijan=20 Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, = Kolkata,=20 India
Tata Consultancy Services
Mailto: abhijan.bhattacharyya@tcs.c= om
Website:=20 http://www.tcs.com
____________________________________________
E= xperience=20 certainty.        IT=20 Services
          &= nbsp;           =20 Business=20 Solutions
          =              = Consulting
____________________________________________

= -----=20 Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM = -----=20

From:       =20 internet-drafts@ietf.org=20
To:       =20 "Soma=20 Bandyopadhyay" <soma.bandyopadhyay@tcs.com= >,=20 "Soma Bandyopadhyay" <soma.bandyopadhyay@tcs.com= >,=20 "Abhijan Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>,=20 "Arpan Pal" <arpan.pal@tcs.com>,=20 "Arpan Pal" <arpan.pal@tcs.com>,=20 "Tulika Bose" <tulika.bose@tcs.com>, = "Abhijan=20 Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>,=20 "Tulika Bose" <tulika.bose@tcs.com> =
Date:       =20 10/15/2015 = 06:45=20 PM
Subject:       =20 New=20 Version Notification for draft-tcs-coap-no-response-option-12.txt =





A new = version of=20 I-D, draft-tcs-coap-no-response-option-12.txt
has been = successfully=20 submitted by Tulika Bose and posted to the
IETF=20 repository.

Name:      &nbs= p;            = ;            =   =20 draft-tcs-coap-no-response-option
Revision:   =             &= nbsp;=20 12
Title:        &nbs= p;            = ;            = =20 CoAP option for no server-response
Document=20 date:           &n= bsp;    =20 2015-10-15
Group:       &n= bsp;           &nb= sp;           &nbs= p; =20 Individual=20 Submission
Pages:       &n= bsp;           &nb= sp;           &nbs= p; =20 17
URL:         =   =20 https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-opt= ion-12.txt
Status:        =20 https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/=
Htmlized:      =20 https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12
Diff:         =  =20 https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-opti= on-12

Abstract:
 =20 There can be M2M scenarios where responses from server=20 against
  requests from client might be considered = redundant.=20 This kind of
  open-loop exchange (with no response = path from=20 the server to the
  client) may be desired to minimize = resource=20 consumption in
  constrained systems while = simultaneously=20 updating a bulk of
  resources or updating a resource = with a=20 very high frequency. CoAP
  already provides a = non-confirmable=20 (NON) mode of message exchange
  where the server = end-point=20 does not respond with ACK. However,
  obeying the=20 request/response semantics, the server end-point
  = responds=20 back with a status code indicating "the result of the
  = attempt=20 to understand and satisfy the request".

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

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =            =20


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

The IETF=20 Secretariat

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

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0086_01D11563.0360B4B0-- From nobody Sun Nov 1 21:52:23 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219F31B47C8 for ; Sun, 1 Nov 2015 21:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sys9DO9_jj43 for ; Sun, 1 Nov 2015 21:52:15 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9261B47B8 for ; Sun, 1 Nov 2015 21:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tA25qBBT026011 for ; Mon, 2 Nov 2015 06:52:11 +0100 (CET) Received: from dhcp-38-127.meeting.ietf94.jp (t20010c4000003032a9e3d969f84844fc.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:a9e3:d969:f848:44fc]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nq3Kj3t8fz2FVr; Mon, 2 Nov 2015 06:52:09 +0100 (CET) Message-ID: <5636FA03.6080708@tzi.org> Date: Mon, 02 Nov 2015 14:52:03 +0900 From: Carsten Bormann User-Agent: Postbox 4.0.7 (Macintosh/20151021) 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] Methods, 2.0 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 05:52:17 -0000 | Code | Name | Code | Name | safe | idempotent | |------+--------+------+--------+------+------------| | 0.01 | GET | 0.05 | FETCH | yes | yes | | 0.02 | POST | 0.06 | PATCH | no | no | | 0.03 | PUT | 0.07 | iPATCH | no | yes | | 0.04 | DELETE | | | no | yes | Hmm. Gr眉脽e, Carsten PS.: I'm still not sure iPATCH shouldn't be called TWEAK or DOCTOR. OK, really now: CHANGE From nobody Mon Nov 2 02:28:36 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02CD1A1B83 for ; Mon, 2 Nov 2015 02:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA1aQBYavrCR for ; Mon, 2 Nov 2015 02:28:29 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 851E71A1B69 for ; Mon, 2 Nov 2015 02:28:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQC6NzdW/wQXEqxeDoJggSBvh1G3awENgVoXAQmFeAKBYhQBAQEBAQEBgQqENQEBAQQBAQEkRwkCEAUEAg0EAwEBASgHJx8JCAYLCBEKiCKTDJxFAQEBhiOLJgEBAQEBAQEBAQEBAQEBAQEBAQEBARiFTGqFP4RFOQyENgWHQYVadTyHd4UdhU+EEhUzg3eSMINyHwEBhAhGaoV+AQEB X-IPAS-Result: A2DPAQC6NzdW/wQXEqxeDoJggSBvh1G3awENgVoXAQmFeAKBYhQBAQEBAQEBgQqENQEBAQQBAQEkRwkCEAUEAg0EAwEBASgHJx8JCAYLCBEKiCKTDJxFAQEBhiOLJgEBAQEBAQEBAQEBAQEBAQEBAQEBARiFTGqFP4RFOQyENgWHQYVadTyHd4UdhU+EEhUzg3eSMINyHwEBhAhGaoV+AQEB X-IronPort-AV: E=Sophos;i="5.20,234,1444674600"; d="scan'208";a="19103545" X-DISCLAIMER: FALSE MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC> References: <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC>, <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com> From: Abhijan Bhattacharyya To: "weigengyu" Message-ID: Date: Mon, 2 Nov 2015 15:58:18 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP4 June 07, 2015 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 15:58:18, Serialize complete at 11/02/2015 15:58:18, Itemize by http on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 15:58:18, Serialize by smdreal on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 15:58:20, Serialize complete at 11/02/2015 15:58:20, Serialize by Router on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 15:58:20 Content-Type: multipart/alternative; boundary="=_alternative 003985EA65257EF1_=" Archived-At: Cc: core@ietf.org Subject: Re: [core] New Version Notification for draft-tcs-coap-no-response-option-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 10:28:36 -0000 --=_alternative 003985EA65257EF1_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Hi Gengyu, The description you quoted tries to clarify that No-Response may not have a= ny effect in saving network traffic (e.g. for a PUT request) when it is use= d in CON mode and the response is supposed to be piggybacked. Because in ca= se of piggybacking you still have the fields for the response code in the r= esponse message even if you are not sending any response.=A0 Regards Abhijan Bhattacharyya Associate Consultant Scientist, Innovation Lab, Kolkata, India Tata Consultancy Services Mailto: abhijan.bhattacharyya@tcs.com Website: http://www.tcs.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Experience certainty. IT Services Business Solutions Consulting =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F -----"weigengyu" wrote: ----- >To: "Rahman, Akbar" , "Abhijan >Bhattacharyya" , >, , >From: "weigengyu" >Date: 11/02/2015 09:08AM >Subject: Re: [core] New Version Notification for >draft-tcs-coap-no-response-option-12.txt > > > > > > > > > > > >Hi Abhijan, >=A0 >one question, >=A0 >> 2. Option Definition >> Using this option with CON type of requests may not have any >=A0=A0=A0=A0=A0 significance if piggybacked responses are=20 >triggered. But, in case >=A0=A0=A0=A0=A0 the server responds with a separate response=20 >(which, may be, the >=A0=A0=A0=A0=A0 client does not care about) then this option=20 >can be useful. >=A0=A0=A0=A0=A0 Suppressing the separate response reduces=20 >one additional traffic >=A0=A0=A0=A0=A0 in this case. >=A0 >The No-reponse option is about request and response layer semantics.=20 >When No-response option works, why the piggybacked responses are >triggered=20 >unless No-response is not recognized.=20 >If the=20 >No-Response option works, it would stop the response whether it is >the=20 >piggybacked or the separated.=20 >It is=20 >uncleatr why it is different between the piggybacked and the >separate. >=A0 >When the=20 >receive ignore the No-Response option, it can response by piggybacked >or=20 >separated way.=20 >Why does=20 >the draft suppose just to suppress the separate response?=A0=A0=A0=20 > >=A0 >And when=20 >the No-Response works, the ACK of CON may contain an empty response.=20 >The=20 >following process of the sender side is the same as definitions for >suppressing=20 >separate response.=A0=20 >=A0 >The CON/ACK=20 >is about the message layer semantics.=20 >It seems=20 >that the No-reponse does not touch the message layer semantics.=20 >=A0 >Regards, >=A0 >Gengyu=20 >WEI >Network Technology Center >School of Computer=20 >Beijing University of=20 >Posts and Telecommunications > > >=A0 > >From: Rahman, Akbar=20 >Sent: Sunday, October 18, 2015 8:17 AM >To: Abhijan Bhattacharyya ; esko.dijk@philips.com ; cabo@tzi.org ; >core@ietf.org=20 >Subject: Re: [core] New Version Notification for=20 >draft-tcs-coap-no-response-option-12.txt >=A0 > > >>Akbar, The reverse=20 >proxy consideration have been included as a new section 4.3. >=A0 >Thanks,=20 >Abhijan.=A0 Looks good. >=A0 >=A0 >=A0 >One=20 >other question, why does the draft say “Expired” at the top=A0= even >though=20 >the expiry date is April 2016? >=A0 >https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >=A0 >=A0 >=A0 >From: Abhijan=20 >Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20 >Sent: Thursday,=20 >October 15, 2015 9:23 AM >To: esko.dijk@philips.com; cabo@tzi.org;=20 >core@ietf.org; Rahman, Akbar=20 > >Subject: Fw: New Version=20 >Notification for draft-tcs-coap-no-response-option-12.txt >=A0 >Hi Carsten, Esko, Akbar=20 >and all,=20 > >Based on the recent=20 >inputs we have shared a new version of the No-Response draft.=20 > > >Esko, I=20 >have actually removed the 'Leisure' stuff for unicast. Thought it was >making=20 >things a bit complicated.=20 > >Akbar, The reverse=20 >proxy consideration have been included as a new section 4.3.=20 > > >Carsten,=20 >requesting your suggestion regarding the next step forward.=20 > >Hoping to see you all=20 >in Yokohama.=20 > >Regards >Abhijan=20 >Bhattacharyya >Associate Consultant >Scientist, Innovation Lab, Kolkata,=20 >India >Tata Consultancy Services >Mailto: abhijan.bhattacharyya@tcs.com >Website:=20 >http://www.tcs.com >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >Experience=20 >certainty.=A0=A0=A0=A0=A0=A0=A0 IT=20 >Services >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 >Business=20 >Solutions >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 >Consulting >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > >-----=20 >Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM >-----=20 > > >From:=FF=FF=FF=FF=FF=FF=FF=20 >internet-drafts@ietf.org=20 > >To:=FF=FF=FF=FF=FF=FF=FF=20 >"Soma=20 >Bandyopadhyay" ,=20 >"Soma Bandyopadhyay" ,=20 >"Abhijan Bhattacharyya" ,=20 >"Arpan Pal" ,=20 >"Arpan Pal" ,=20 >"Tulika Bose" , "Abhijan=20 >Bhattacharyya" ,=20 >"Tulika Bose" =20 >Date:=FF=FF=FF=FF=FF=FF=FF=20 >10/15/2015 06:45=20 >PM=20 >Subject:=FF=FF=FF=FF=FF=FF=FF=20 >New=20 >Version Notification for draft-tcs-coap-no-response-option-12.txt=20 > > > > > > > > >A new version of=20 >I-D, draft-tcs-coap-no-response-option-12.txt >has been successfully=20 >submitted by Tulika Bose and posted to the >IETF=20 >repository. > >Name:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >draft-tcs-coap-no-response-option >Revision:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >12 >Title:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >CoAP option for no server-response >Document=20 >date:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >2015-10-15 >Group:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >Individual=20 >Submission >Pages:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF= =FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >17 >URL:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio >n-12.txt >Status:=FF=FF=FF=FF=FF=FF=FF=FF=20 >https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ >Htmlized:=FF=FF=FF=FF=FF=FF=20 >https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >Diff:=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-1 >2 > >Abstract: >=FF=20 >There can be M2M scenarios where responses from server=20 >against >=FF requests from client might be considered redundant.=20 >This kind of >=FF open-loop exchange (with no response path from=20 >the server to the >=FF client) may be desired to minimize resource=20 >consumption in >=FF constrained systems while simultaneously=20 >updating a bulk of >=FF resources or updating a resource with a=20 >very high frequency. CoAP >=FF already provides a non-confirmable=20 >(NON) mode of message exchange >=FF where the server end-point=20 >does not respond with ACK. However, >=FF obeying the=20 >request/response semantics, the server end-point >=FF responds=20 >back with a status code indicating "the result of the >=FF attempt=20 >to understand and satisfy the request". > >=FF This draft=20 >introduces a header option for CoAP called 'No-Response'. >=FF=20 >Using this option the client explicitly tells the server to=20 >suppress >=FF responses against the particular request. This=20 >option also provides >=FF granular control to enable suppression=20 >of a particular class or a >=FF combination of response-classes.=20 >This option may be effective for >=FF both unicast and multicast=20 >requests. Present draft also discusses >=FF few exemplary=20 >applications which benefit from this=20 >option. > > >=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=20 > > > >Please note that it may take a couple of minutes from the=20 >time of submission >until the htmlized version and diff are available=20 >at tools.ietf.org. > >The IETF=20 >Secretariat >=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D >Notice: The information contained in this=20 >e-mail >message and/or attachments to it may contain=20 >confidential or=20 >privileged information. If you are=20 >not the intended recipient, any=20 >dissemination, use,=20 >review, distribution, printing or copying of the=20 > >information contained in this e-mail message=20 >and/or attachments to it=20 >are strictly prohibited. If=20 >you have received this communication in error,=20 > >please notify us by reply e-mail or telephone and=20 >immediately and=20 >permanently delete the message=20 >and any attachments. Thank=20 >you > > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >core mailing=20 >list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core > > --=_alternative 003985EA65257EF1_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Content-ID: <>
Hi Gengyu,
The description you quoted tries to clarif= y that No-Response may not have any effect in saving network traffic (e.g. = for a PUT request) when it is used in CON mode and the response is supposed= to be piggybacked. Because in case of piggybacking you still have the fiel= ds for the response code in the response message even if you are not sendin= g any response. 


-----"weigengyu" <weigengyu@bupt.edu.cn> wrote: -----=

>To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>= ;, "Abhijan
>Bhattacharyya" <abhijan.bhattacharyya@tcs.com>,><esko.dijk@philips.com>, <cabo@tzi.org>, <core@ietf.org= >
>From: "weigengyu" <weigengyu@bupt.edu.cn>
>Date: 11= /02/2015 09:08AM
>Subject: Re: [core] New Version Notification for>draft-tcs-coap-no-response-option-12.txt
>
>
>
&g= t;
>
>
><!--
>/* Font Definitions */
>@fon= t-face
> {font-family:"Cambria Math";
> panose-1:2 4 5 3 5 4 6 = 3 2 4;}
>@font-face
> {font-family:Calibri;
> panose-1:2 = 15 5 2 2 2 4 3 2 4;}
>/* Style Definitions */
>p.MsoNormal, li.= MsoNormal, div.MsoNormal
> {margin:0in;
> margin-bottom:.0001pt= ;
> font-size:12.0pt;
> font-family:"Times New Roman",serif;}>a:link, span.MsoHyperlink
> {mso-style-priority:99;
> col= or:blue;
> text-decoration:underline;}
>a:visited, span.MsoHype= rlinkFollowed
> {mso-style-priority:99;
> color:purple;
>= text-decoration:underline;}
>p
> {mso-style-priority:99;
&g= t; mso-margin-top-alt:auto;
> margin-right:0in;
> mso-margin-bo= ttom-alt:auto;
> margin-left:0in;
> font-size:12.0pt;
> f= ont-family:"Times New Roman",serif;}
>tt
> {mso-style-priority:= 99;
> font-family:"Courier New";}
>span.EmailStyle19
> {m= so-style-type:personal-reply;
> font-family:"Calibri",sans-serif;
= > color:#1F497D;}
>.MsoChpDefault
> {mso-style-type:export-o= nly;
> font-family:"Calibri",sans-serif;}
>@page WordSection1> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;}
>= div.WordSection1
> {page:WordSection1;}
>-->
>
>=
>
>
>Hi Abhijan,
> 
>one question,
&= gt; 
>> 2. Option Definition
>> Using this option wi= th CON type of requests may not have any
>    &nb= sp; significance if piggybacked responses are
>triggered. But, in ca= se
>      the server responds with a separat= e response
>(which, may be, the
>     = ; client does not care about) then this option
>can be useful.
&g= t;      Suppressing the separate response reduces =
>one additional traffic
>      in thi= s case.
> 
>The No-reponse option is about request and res= ponse layer semantics.
>When No-response option works, why the piggy= backed responses are
>triggered
>unless No-response is not rec= ognized.
>If the
>No-Response option works, it would stop the= response whether it is
>the
>piggybacked or the separated. >It is
>uncleatr why it is different between the piggybacked an= d the
>separate.
> 
>When the
>receive ignore= the No-Response option, it can response by piggybacked
>or
>s= eparated way.
>Why does
>the draft suppose just to suppress t= he separate response?   
>
> 
>And w= hen
>the No-Response works, the ACK of CON may contain an empty resp= onse.
>The
>following process of the sender side is the same = as definitions for
>suppressing
>separate response. 
= > 
>The CON/ACK
>is about the message layer semantics.=
>It seems
>that the No-reponse does not touch the message la= yer semantics.
> 
>Regards,
> 
>Gengyu <= br>>WEI
>Network Technology Center
>School of Computer
&= gt;Beijing University of
>Posts and Telecommunications
>
&g= t;
> 
>
>From: Rahman, Akbar
>Sent: Sunday, O= ctober 18, 2015 8:17 AM
>To: Abhijan Bhattacharyya ; esko.dijk@philip= s.com ; cabo@tzi.org ;
>core@ietf.org
>Subject: Re: [core] New= Version Notification for
>draft-tcs-coap-no-response-option-12.txt<= br>> 
>
>
>>Akbar, The reverse
>proxy c= onsideration have been included as a new section 4.3.
> 
>= Thanks,
>Abhijan.  Looks good.
> 
> 
&= gt; 
>One
>other question, why does the draft say “= Expired” at the top  even
>though
>the expiry date = is April 2016?
> 
>https://tools.ietf.org/html/draft-tcs-c= oap-no-response-option-12
> 
> 
> 
>= From: Abhijan
>Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com] =
>Sent: Thursday,
>October 15, 2015 9:23 AM
>To: esko.di= jk@philips.com; cabo@tzi.org;
>core@ietf.org; Rahman, Akbar
>= <Akbar.Rahman@InterDigital.com>
>Subject: Fw: New Version
&= gt;Notification for draft-tcs-coap-no-response-option-12.txt
> <= br>>Hi Carsten, Esko, Akbar
>and all,
>
>Based on th= e recent
>inputs we have shared a new version of the No-Response dra= ft.
>
>
>Esko, I
>have actually removed the 'Leis= ure' stuff for unicast. Thought it was
>making
>things a bit c= omplicated.
>
>Akbar, The reverse
>proxy consideration = have been included as a new section 4.3.
>
>
>Carsten, <= br>>requesting your suggestion regarding the next step forward.
>=
>Hoping to see you all
>in Yokohama.
>
>Regards<= br>>Abhijan
>Bhattacharyya
>Associate Consultant
>Sci= entist, Innovation Lab, Kolkata,
>India
>Tata Consultancy Serv= ices
>Mailto: abhijan.bhattacharyya@tcs.com
>Website:
>h= ttp://www.tcs.com
>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
>Experience
>certainty.     = ;   IT
>Services
>     &nbs= p;            &= nbsp;   
>Business
>Solutions
> &nb= sp;            =         
>Consulting
>= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>
>--= ---
>Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 = PM
>-----
>
>
>From:     =   
>internet-drafts@ietf.org
>
>To: &nbs= p;     
>"Soma
>Bandyopadhyay" <s= oma.bandyopadhyay@tcs.com>,
>"Soma Bandyopadhyay" <soma.bandyo= padhyay@tcs.com>,
>"Abhijan Bhattacharyya" <abhijan.bhattachar= yya@tcs.com>,
>"Arpan Pal" <arpan.pal@tcs.com>,
>"Ar= pan Pal" <arpan.pal@tcs.com>,
>"Tulika Bose" <tulika.bose@t= cs.com>, "Abhijan
>Bhattacharyya" <abhijan.bhattacharyya@tcs.c= om>,
>"Tulika Bose" <tulika.bose@tcs.com>
>Date:&nbs= p;      
>10/15/2015 06:45
>PM =
>Subject:       
>New
= >Version Notification for draft-tcs-coap-no-response-option-12.txt
&= gt;
>
>
>
>
>
>
>
>A new ve= rsion of
>I-D, draft-tcs-coap-no-response-option-12.txt
>has b= een successfully
>submitted by Tulika Bose and posted to the
>= IETF
>repository.
>
>Name:     =             &nb= sp;            =    
>draft-tcs-coap-no-response-option
>Revisio= n:            &= nbsp;   
>12
>Title:    &nb= sp;            =             &nb= sp;   
>CoAP option for no server-response
>Doc= ument
>date:         &n= bsp;      
>2015-10-15
>Group:&n= bsp;            = ;            &n= bsp;       
>Individual
>S= ubmission
>Pages:        &nbs= p;            &= nbsp;            >17
>URL:         &n= bsp; 
>https://www.ietf.org/internet-drafts/draft-tcs-coap-no-r= esponse-optio
>n-12.txt
>Status:     &= nbsp;  
>https://datatracker.ietf.org/doc/draft-tcs-coap-n= o-response-option/
>Htmlized:       >https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12
&g= t;Diff:          
>= ;https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-1>2
>
>Abstract:
> 
>There can be M2M scen= arios where responses from server
>against
>  requests fr= om client might be considered redundant.
>This kind of
> = open-loop exchange (with no response path from
>the server to the>  client) may be desired to minimize resource
>consumptio= n in
>  constrained systems while simultaneously
>updatin= g a bulk of
>  resources or updating a resource with a
>v= ery high frequency. CoAP
>  already provides a non-confirmable <= br>>(NON) mode of message exchange
>  where the server end-po= int
>does not respond with ACK. However,
>  obeying the <= br>>request/response semantics, the server end-point
>  respo= nds
>back with a status code indicating "the result of the
>&n= bsp; attempt
>to understand and satisfy the request".
>
>= ;  This draft
>introduces a header option for CoAP called 'No-R= esponse'.
> 
>Using this option the client explicitly tel= ls the server to
>suppress
>  responses against the parti= cular request. This
>option also provides
>  granular con= trol to enable suppression
>of a particular class or a
> = combination of response-classes.
>This option may be effective for<= br>>  both unicast and multicast
>requests. Present draft al= so discusses
>  few exemplary
>applications which benefit= from this
>option.
>
>
>    &= nbsp;      
>
>
>
>P= lease note that it may take a couple of minutes from the
>time of su= bmission
>until the htmlized version and diff are available
>a= t tools.ietf.org.
>
>The IETF
>Secretariat
>=3D=3D= =3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D
>Notice: The inform= ation 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
>
>i= nformation contained in this e-mail message
>and/or attachments to i= t
>are strictly prohibited. If
>you have received this commun= ication in error,
>
>please notify us by reply e-mail or telep= hone and
>immediately and
>permanently delete the message >and any attachments. Thank
>you
>
>
>=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>core ma= iling
>list
>core@ietf.org
>https://www.ietf.org/mailman= /listinfo/core
>
> --=_alternative 003985EA65257EF1_=-- From nobody Mon Nov 2 02:36:09 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BDC1A1BAC for ; Mon, 2 Nov 2015 02:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujTPSN7c1V2H for ; Mon, 2 Nov 2015 02:36:06 -0800 (PST) Received: from inkolg01.tcs.com (inkolg01.tcs.com [121.241.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4023C1A1B9A for ; Mon, 2 Nov 2015 02:36:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DPAQBAOzdW/wQXEqxehA5vh1G3awENgVohhXQCAgKBZBQBAQEBAQEBgQqENQECBHcXBg0EAwECKE0HAggGAQoIEQqIIq9OAQEBkUgBAQEBBgEBAQEBHoVMaoU/hEU5gy6BFAWNG3WIM4UdiWFIg3eNUIhSHwEBhE5qhX4BAQE X-IPAS-Result: A2DPAQBAOzdW/wQXEqxehA5vh1G3awENgVohhXQCAgKBZBQBAQEBAQEBgQqENQECBHcXBg0EAwECKE0HAggGAQoIEQqIIq9OAQEBkUgBAQEBBgEBAQEBHoVMaoU/hEU5gy6BFAWNG3WIM4UdiWFIg3eNUIhSHwEBhE5qhX4BAQE X-IronPort-AV: E=Sophos;i="5.20,234,1444674600"; d="scan'208";a="19106804" MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Abhijan Bhattacharyya To: , "Carsten Bormann" , Message-ID: Date: Mon, 2 Nov 2015 16:06:00 +0530 X-Mailer: Lotus Domino Web Server Release 9.0.1FP4 June 07, 2015 X-MIMETrack: Serialize by http on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 16:06:00, Serialize complete at 11/02/2015 16:06:01, Itemize by http on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 16:06:01, Serialize by smdreal on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 16:06:02, Serialize complete at 11/02/2015 16:06:02, Serialize by Router on InKolM02/TCS(Release 9.0.1FP4|June 07, 2015) at 11/02/2015 16:06:02 Content-Type: multipart/alternative; boundary="=_alternative 003A3A9165257EF1_=" Archived-At: Subject: [core] Fw: New Version Notification for draft-tcs-coap-no-response-option-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 10:36:08 -0000 --=_alternative 003A3A9165257EF1_= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, We have submitted a new version of the No-Response draft. This addresses th= e last comments received from Esko. Carsten,=A0 May I please request you to update the version number in the meeting materi= als. Sorry for the late action. Was stuck with some issues with my mail ser= ver. =A0 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 11/02/2015 04:00PM ----- >To: "Soma Bandyopadhyay" , "Abhijan >Bhattacharyya" , "Arpan Pal" >, "Tulika Bose" >From: internet-drafts@ietf.org >Date: 11/02/2015 03:59PM >Subject: New Version Notification for >draft-tcs-coap-no-response-option-13.txt > >A new version of I-D, draft-tcs-coap-no-response-option-13.txt >has been successfully submitted by Abhijan Bhattacharyya and posted >to the >IETF repository. > >Name: draft-tcs-coap-no-response-option >Revision: 13 >Title: CoAP option for no server-response >Document date: 2015-11-02 >Group: Individual Submission >Pages: 17 >URL: >https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio >n-13.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-13 >Diff: >https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-1 >3 > >Abstract: > There can be M2M scenarios where responses from server against > requests from client might be considered 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 simultaneously updating a bulk of > resources or updating a resource with a very high frequency. CoAP > already provides a non-confirmable (NON) mode of message exchange > where the server end-point does not respond with ACK. However, > obeying the request/response semantics, the server end-point > responds back with a status code indicating "the result of the > attempt to understand and satisfy the request". > > This draft introduces a header option for CoAP called >'No-Response'. > Using this option the client explicitly tells the server to >suppress > responses against the particular request. This option also >provides > granular control to enable suppression of a particular class or a > combination of response-classes. This option may be effective for > both unicast and multicast requests. Present draft also discusses > 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 > > =3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D Notice: The information contained in this e-mail message and/or attachments to it may contain = confidential or privileged information. If you are = not the intended recipient, any dissemination, use, = review, distribution, printing or copying of the = information contained in this e-mail message = and/or attachments to it are strictly prohibited. If = you have received this communication in error, = please notify us by reply e-mail or telephone and = immediately and permanently delete the message = and any attachments. Thank you --=_alternative 003A3A9165257EF1_= Content-ID: <> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
We have submitted a new version of the No-R= esponse draft. This addresses the last comments received from Esko.

Carsten, 
May I please request you to upda= te the version number in the meeting materials. Sorry for the late action. = Was stuck with some issues with my mail server.  

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 Bhat= tacharyya/KOL/TCS on 11/02/2015 04:00PM -----

>To: "Soma B= andyopadhyay" <soma.bandyopadhyay@tcs.com>, "Abhijan
>Bhattacha= ryya" <abhijan.bhattacharyya@tcs.com>, "Arpan Pal"
><arpan.p= al@tcs.com>, "Tulika Bose" <tulika.bose@tcs.com>
>From: inte= rnet-drafts@ietf.org
>Date: 11/02/2015 03:59PM
>Subject: New Ve= rsion Notification for
>draft-tcs-coap-no-response-option-13.txt
&= gt;
>A new version of I-D, draft-tcs-coap-no-response-option-13.txt>has been successfully submitted by Abhijan Bhattacharyya and posted>to the
>IETF repository.
>
>Name: draft-tcs-coap-n= o-response-option
>Revision: 13
>Title: CoAP option for no ser= ver-response
>Document date: 2015-11-02
>Group: Individual Sub= mission
>Pages: 17
>URL:
>https://www.ietf.org/internet-= drafts/draft-tcs-coap-no-response-optio
>n-13.txt
>Status:
&= gt;https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/
&= gt;Htmlized:
>https://tools.ietf.org/html/draft-tcs-coap-no-response-= option-13
>Diff:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs= -coap-no-response-option-1
>3
>
>Abstract:
> Ther= e can be M2M scenarios where responses from server against
> reques= ts from client might be considered redundant. This kind of
> open-l= oop exchange (with no response path from the server to the
> client= ) may be desired to minimize resource consumption in
> constrained = systems while simultaneously updating a bulk of
> resources or upda= ting a resource with a very high frequency. CoAP
> already provides= a non-confirmable (NON) mode of message exchange
> where the serve= r end-point does not respond with ACK. However,
> obeying the reque= st/response semantics, the server end-point
> responds back with a = status code indicating "the result of the
> attempt to understand a= nd satisfy the request".
>
> This draft introduces a header o= ption for CoAP called
>'No-Response'.
> Using this option the= client explicitly tells the server to
>suppress
> responses = against the particular request. This option also
>provides
> = granular control to enable suppression of a particular class or a
> = combination of response-classes. This option may be effective for
> = both unicast and multicast requests. Present draft also discusses
>= few exemplary applications which benefit from this option.
>
&g= t;
>
>
>
>Please note that it may take = a couple of minutes from the time of
>submission
>until the htm= lized version and diff are available at tools.ietf.org.
>
>The = IETF Secretariat
>
>

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

--=_alternative 003A3A9165257EF1_=-- From nobody Mon Nov 2 20:38:33 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508C41B2DA8 for ; Mon, 2 Nov 2015 20:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QScV7qCRqjAE for ; Mon, 2 Nov 2015 20:38:31 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 80FC71B2D9D for ; Mon, 2 Nov 2015 20:38:30 -0800 (PST) Received: by lfgh9 with SMTP id h9so4751529lfg.1 for ; Mon, 02 Nov 2015 20:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ygsScQMPh4BwDvMyMyEc3A1kvNs3Y34uvH4SKtd+4X8=; b=f9A1o2w75XA7I68UmbfG0DMdJitqONfyz7zMHs34UU45RmLzWl6WBNOAxo96rPDsqj 7fOyemwhhzAPLw8MdiqvR3BjbE8+8fYxQzG7nN+TS61RLwhd24MJuXGJsKXCfLYY0GFd Vrcy6KtEkCnrrnOv/g0jRuAcoHUox8udpYYgEdcOPmZSq3Ka+9ybQ9w2cl/Kq/fKDMLY OYgqPw3Swm8SqZhT+uN156GtJd8OMJCNdGmY0gfoQwm3XYdN8SvMrccIxfG5VQb9zpfV ozJUZEfzlvwYl7Tjb7zfluSMvRa6zUrNb9LecDZWdhLQd5Bi7hMiseVLMnRoUE2A0r3Z M91A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ygsScQMPh4BwDvMyMyEc3A1kvNs3Y34uvH4SKtd+4X8=; b=GiIHROAVmIcZrR72MDP5xFHu5n5QfO14UdtMIgJpaUb0RCaiq7uh+SaCQCQ9BSM9iD RcHVslYXwwsma+AkJ2aNpv6jjOcvswkUFdf0AcDQ50l14DBhwR8ZfcPIQ1LQ4962RiPc hmbIU9x8Vyurb+IEmYQHG2zabFWlYrJ0fUr+RDCEQ5Si76RzaeO3l9x2fNz5Pc+9ZrLA xaMuPMVw3qFCFClBsJRgI2HNYwFLwFJ+hSEucAozqDr14nUXKDXg/DaB7LE6OOxE3RLI Zy7Q3t7vwpewndiI2RFWYd0+nE3ZiH+XhquKPSNprINcWmRKbx/YT3lovBYK7sNHcs+w Tafg== X-Gm-Message-State: ALoCoQnGSZCtJHMqIhup7KzimG8UkO8XjIGjr0sohn9I+vf3TkUNcW9C2VhYTHjzFzfVbg4R3acG MIME-Version: 1.0 X-Received: by 10.25.17.78 with SMTP id g75mr7926224lfi.12.1446525508575; Mon, 02 Nov 2015 20:38:28 -0800 (PST) Received: by 10.114.183.135 with HTTP; Mon, 2 Nov 2015 20:38:28 -0800 (PST) Date: Tue, 3 Nov 2015 15:38:28 +1100 Message-ID: From: Andrew Mcgregor To: Core Content-Type: multipart/alternative; boundary=001a11406dd819292805239b7763 Archived-At: Subject: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:38:32 -0000 --001a11406dd819292805239b7763 Content-Type: text/plain; charset=UTF-8 The sense of the room at IETF 94 was that we should adopt this as a working group document. This is the corresponding mailing list call, open until November 16. Title : A TCP and TLS Transport for the Constrained Application Protocol (CoAP) Authors : Carsten Bormann Simon Lemay Valik Solorzano Barboza Hannes Tschofenig Filename : draft-tschofenig-core-coap-tcp-tls-05.txt Pages : 12 Date : 2015-11-02 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-tschofenig-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a11406dd819292805239b7763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The sense of the room at IETF 94 was that we should adopt = this as a working group document.

This is the correspond= ing mailing list call, open until November 16.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A TCP and TLS Transport for the Constraine= d Application Protocol (CoAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: Carsten Bormann
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Simon Lemay
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V= alik Solorzano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tschofenig-core-coap-tcp-tls-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-11-02

Abstract:
=C2=A0 =C2=A0The Hypertext Transfer Protocol (HTTP) was designed= with TCP as the
=C2=A0 =C2=A0underlying transport protocol.=C2=A0 The Constrain= ed Application Protocol
=C2=A0 =C2=A0(CoAP), while inspired by HTTP, has been de= fined to make use of UDP
=C2=A0 =C2=A0instead of TCP.=C2=A0 Therefore, reliabl= e delivery and a simple congestion
=C2=A0 =C2=A0control and flow control mechani= sm are provided by the message layer
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0of the CoAP protocol.
=C2=A0 =C2=A0A number of environments benefit from the us= e of CoAP directly over a
=C2=A0 =C2=A0reliable byte stream such as TCP, which = already provides these
=C2=A0 =C2=A0services.=C2=A0 This document defines the us= e of CoAP over TCP as well as
=C2=A0 =C2=A0CoAP over TLS.


The IETF datatracker status page for thi= s draft is:
https://datatracker.ietf.org/do= c/draft-tschofenig-core-coap-tcp-tls/
There's al= so a htmlized version available at:
https://to= ols.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-c= oap-tcp-tls-05

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0a= ndrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221
--001a11406dd819292805239b7763-- From nobody Thu Nov 5 00:04:09 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586561B2B60 for ; Thu, 5 Nov 2015 00:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqqk1zGqtEsg for ; Thu, 5 Nov 2015 00:04:03 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id DFADC1B3BE8 for ; Thu, 5 Nov 2015 00:04:01 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id C923719F5D9 for ; Thu, 5 Nov 2015 16:03:58 +0800 (HKT) Received: from WeiGengyuPC (unknown [61.51.83.92]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 35BC019F568; Thu, 5 Nov 2015 16:03:58 +0800 (HKT) Message-ID: <79A9C92DDABA437888A06EB0D82BA110@WeiGengyuPC> From: "weigengyu" To: "Abhijan Bhattacharyya" References: <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC>, <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com> In-Reply-To: Date: Thu, 5 Nov 2015 16:03:59 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D117E3.94CE7B30" 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] New Version Notification for draft-tcs-coap-no-response-option-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:04:08 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_002F_01D117E3.94CE7B30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Abhijan, In your draft, there is not other contexts about piggybacked and = separate response.=20 With these statements, =E2=80=9CUsing this option with CON type of requests may not have any significance if piggybacked responses are triggered. But, in case the server responds with a separate response (which, may be, the client does not care about) then this option can be useful. Suppressing the separate response reduces one additional traffic in this case. =E2=80=9C , the piggybacked response may be sent back and the separate response may = be suppressed.=20 Why not to suppress the piggybacked response?=20 Even though an ACK of CON is needed, the ACK could be with an empty = response instead of a nomormal response. And if the piggybacked response is not suppressed, =20 should the sender expect the suppressed separate response?=20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Abhijan Bhattacharyya=20 Sent: Monday, November 02, 2015 6:28 PM To: weigengyu=20 Cc: Akbar.Rahman@InterDigital.com ; esko.dijk@philips.com ; cabo@tzi.org = ; core@ietf.org=20 Subject: Re: [core] New Version Notification for = draft-tcs-coap-no-response-option-12.txt Hi Gengyu, The description you quoted tries to clarify that No-Response may not = have any effect in saving network traffic (e.g. for a PUT request) when = it is used in CON mode and the response is supposed to be piggybacked. = Because in case of piggybacking you still have the fields for the = response code in the response message even if you are not sending any = response.=20 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 ____________________________________________ -----"weigengyu" wrote: ----- >To: "Rahman, Akbar" , "Abhijan >Bhattacharyya" , >, , >From: "weigengyu" >Date: 11/02/2015 09:08AM >Subject: Re: [core] New Version Notification for >draft-tcs-coap-no-response-option-12.txt > > > > > > > > > > > >Hi Abhijan, >=20 >one question, >=20 >> 2. Option Definition >> Using this option with CON type of requests may not have any > significance if piggybacked responses are=20 >triggered. But, in case > the server responds with a separate response=20 >(which, may be, the > client does not care about) then this option=20 >can be useful. > Suppressing the separate response reduces=20 >one additional traffic > in this case. >=20 >The No-reponse option is about request and response layer semantics.=20 >When No-response option works, why the piggybacked responses are >triggered=20 >unless No-response is not recognized.=20 >If the=20 >No-Response option works, it would stop the response whether it is >the=20 >piggybacked or the separated.=20 >It is=20 >uncleatr why it is different between the piggybacked and the >separate. >=20 >When the=20 >receive ignore the No-Response option, it can response by piggybacked >or=20 >separated way.=20 >Why does=20 >the draft suppose just to suppress the separate response? =20 > >=20 >And when=20 >the No-Response works, the ACK of CON may contain an empty response.=20 >The=20 >following process of the sender side is the same as definitions for >suppressing=20 >separate response. =20 >=20 >The CON/ACK=20 >is about the message layer semantics.=20 >It seems=20 >that the No-reponse does not touch the message layer semantics.=20 >=20 >Regards, >=20 >Gengyu=20 >WEI >Network Technology Center >School of Computer=20 >Beijing University of=20 >Posts and Telecommunications > > >=20 > >From: Rahman, Akbar=20 >Sent: Sunday, October 18, 2015 8:17 AM >To: Abhijan Bhattacharyya ; esko.dijk@philips.com ; cabo@tzi.org ; >core@ietf.org=20 >Subject: Re: [core] New Version Notification for=20 >draft-tcs-coap-no-response-option-12.txt >=20 > > >>Akbar, The reverse=20 >proxy consideration have been included as a new section 4.3. >=20 >Thanks,=20 >Abhijan. Looks good. >=20 >=20 >=20 >One=20 >other question, why does the draft say =E2=80=9CExpired=E2=80=9D at the = top even >though=20 >the expiry date is April 2016? >=20 >https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >=20 >=20 >=20 >From: Abhijan=20 >Bhattacharyya [mailto:abhijan.bhattacharyya@tcs.com]=20 >Sent: Thursday,=20 >October 15, 2015 9:23 AM >To: esko.dijk@philips.com; cabo@tzi.org;=20 >core@ietf.org; Rahman, Akbar=20 > >Subject: Fw: New Version=20 >Notification for draft-tcs-coap-no-response-option-12.txt >=20 >Hi Carsten, Esko, Akbar=20 >and all,=20 > >Based on the recent=20 >inputs we have shared a new version of the No-Response draft.=20 > > >Esko, I=20 >have actually removed the 'Leisure' stuff for unicast. Thought it was >making=20 >things a bit complicated.=20 > >Akbar, The reverse=20 >proxy consideration have been included as a new section 4.3.=20 > > >Carsten,=20 >requesting your suggestion regarding the next step forward.=20 > >Hoping to see you all=20 >in Yokohama.=20 > >Regards >Abhijan=20 >Bhattacharyya >Associate Consultant >Scientist, Innovation Lab, Kolkata,=20 >India >Tata Consultancy Services >Mailto: abhijan.bhattacharyya@tcs.com >Website:=20 >http://www.tcs.com >____________________________________________ >Experience=20 >certainty. IT=20 >Services > =20 >Business=20 >Solutions > =20 >Consulting >____________________________________________ > >-----=20 >Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45 PM >-----=20 > > >From: =20 >internet-drafts@ietf.org=20 > >To: =20 >"Soma=20 >Bandyopadhyay" ,=20 >"Soma Bandyopadhyay" ,=20 >"Abhijan Bhattacharyya" ,=20 >"Arpan Pal" ,=20 >"Arpan Pal" ,=20 >"Tulika Bose" , "Abhijan=20 >Bhattacharyya" ,=20 >"Tulika Bose" =20 >Date: =20 >10/15/2015 06:45=20 >PM=20 >Subject: =20 >New=20 >Version Notification for draft-tcs-coap-no-response-option-12.txt=20 > > > > > > > > >A new version of=20 >I-D, draft-tcs-coap-no-response-option-12.txt >has been successfully=20 >submitted by Tulika Bose and posted to the >IETF=20 >repository. > >Name: =20 >draft-tcs-coap-no-response-option >Revision: =20 >12 >Title: =20 >CoAP option for no server-response >Document=20 >date: =20 >2015-10-15 >Group: =20 >Individual=20 >Submission >Pages: =20 >17 >URL: =20 >https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-optio >n-12.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ >Htmlized: =20 >https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option-1 >2 > >Abstract: > =20 >There can be M2M scenarios where responses from server=20 >against > requests from client might be considered redundant.=20 >This kind of > open-loop exchange (with no response path from=20 >the server to the > client) may be desired to minimize resource=20 >consumption in > constrained systems while simultaneously=20 >updating a bulk of > resources or updating a resource with a=20 >very high frequency. CoAP > already provides a non-confirmable=20 >(NON) mode of message exchange > where the server end-point=20 >does not respond with ACK. However, > obeying the=20 >request/response semantics, the server end-point > responds=20 >back with a status code indicating "the result of the > attempt=20 >to understand and satisfy the request". > > This draft=20 >introduces a header option for CoAP called 'No-Response'. > =20 >Using this option the client explicitly tells the server to=20 >suppress > responses against the particular request. This=20 >option also provides > granular control to enable suppression=20 >of a particular class or a > combination of response-classes.=20 >This option may be effective for > both unicast and multicast=20 >requests. Present draft also discusses > few exemplary=20 >applications which benefit from this=20 >option. > > > =20 > > > >Please note that it may take a couple of minutes from the=20 >time of submission >until the htmlized version and diff are available=20 >at tools.ietf.org. > >The IETF=20 >Secretariat >=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D >Notice: The information contained in this=20 >e-mail >message and/or attachments to it may contain=20 >confidential or=20 >privileged information. If you are=20 >not the intended recipient, any=20 >dissemination, use,=20 >review, distribution, printing or copying of the=20 > >information contained in this e-mail message=20 >and/or attachments to it=20 >are strictly prohibited. If=20 >you have received this communication in error,=20 > >please notify us by reply e-mail or telephone and=20 >immediately and=20 >permanently delete the message=20 >and any attachments. Thank=20 >you > > >_______________________________________________ >core mailing=20 >list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core > > ------=_NextPart_000_002F_01D117E3.94CE7B30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Abhijan,
 
In your draft, there is not other contexts about piggybacked and = separate=20 response.
With these statements,
=E2=80=9CUsing this option with CON type of requests may not have = any
      significance if piggybacked = responses are=20 triggered. But, in case
      the server responds with a separate = response=20 (which, may be, the
      client does not care about) then = this option=20 can be useful.
      Suppressing the separate response = reduces=20 one additional traffic
      in this case. =E2=80=9C ,
 
the piggybacked response may be sent back and the separate response = may be=20 suppressed.
Why not to suppress the piggybacked response?
Even though an ACK of CON is needed, the ACK could be with an empty = response instead of a nomormal response.

And if the piggybacked response is not suppressed, 
should the sender expect the suppressed separate response?
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Abhijan Bhattacharyya =
Sent: Monday, November 02, 2015 6:28 PM
Cc: Akbar.Rahman@InterDigital.c= om ;=20 esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org =
Subject: Re: [core] New Version Notification for=20 draft-tcs-coap-no-response-option-12.txt
 
Hi Gengyu,
The description you quoted tries to clarify that No-Response may = not have=20 any effect in saving network traffic (e.g. for a PUT request) when it is = used in=20 CON mode and the response is supposed to be piggybacked. Because in case = of=20 piggybacking you still have the fields for the response code in the = response=20 message even if you are not sending any response.

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

-----"weigengyu" <weigengyu@bupt.edu.cn> wrote:=20 -----

>To: "Rahman, Akbar"=20 <Akbar.Rahman@InterDigital.com>, "Abhijan
>Bhattacharyya"=20 <abhijan.bhattacharyya@tcs.com>,
><esko.dijk@philips.com&g= t;,=20 <cabo@tzi.org>, <core@ietf.org>
>From: "weigengyu"=20 <weigengyu@bupt.edu.cn>
>Date: 11/02/2015 = 09:08AM
>Subject:=20 Re: [core] New Version Notification=20 for
>draft-tcs-coap-no-response-option-12.txt
>
>
&g= t;
>
>
>
><!--
>/*=20 Font Definitions */
>@font-face
> {font-family:"Cambria=20 Math";
> panose-1:2 4 5 3 5 4 6 3 2 4;}
>@font-face
>=20 {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
>/* = Style=20 Definitions */
>p.MsoNormal, li.MsoNormal, div.MsoNormal
>=20 {margin:0in;
> margin-bottom:.0001pt;
> = font-size:12.0pt;
>=20 font-family:"Times New Roman",serif;}
>a:link, = span.MsoHyperlink
>=20 {mso-style-priority:99;
> color:blue;
>=20 text-decoration:underline;}
>a:visited, = span.MsoHyperlinkFollowed
>=20 {mso-style-priority:99;
> color:purple;
>=20 text-decoration:underline;}
>p
> = {mso-style-priority:99;
>=20 mso-margin-top-alt:auto;
> margin-right:0in;
>=20 mso-margin-bottom-alt:auto;
> margin-left:0in;
>=20 font-size:12.0pt;
> font-family:"Times New=20 Roman",serif;}
>tt
> {mso-style-priority:99;
>=20 font-family:"Courier New";}
>span.EmailStyle19
>=20 {mso-style-type:personal-reply;
>=20 font-family:"Calibri",sans-serif;
>=20 color:#1F497D;}
>.MsoChpDefault
>=20 {mso-style-type:export-only;
>=20 font-family:"Calibri",sans-serif;}
>@page WordSection1
> = {size:8.5in=20 11.0in;
> margin:1.0in 1.0in 1.0in = 1.0in;}
>div.WordSection1
>=20 {page:WordSection1;}
>-->
>
>
>
>
>= ;Hi=20 Abhijan,
>
>one question,
>
>> 2. Option=20 Definition
>> Using this option with CON type of requests may = not have=20 any
>      significance if piggybacked = responses=20 are
>triggered. But, in = case
>      the=20 server responds with a separate response
>(which, may be,=20 the
>      client does not care about) = then this=20 option
>can be useful.
>      = Suppressing=20 the separate response reduces
>one additional=20 traffic
>      in this case.
> =
>The=20 No-reponse option is about request and response layer semantics. =
>When=20 No-response option works, why the piggybacked responses = are
>triggered=20
>unless No-response is not recognized.
>If the =
>No-Response=20 option works, it would stop the response whether it is
>the=20
>piggybacked or the separated.
>It is
>uncleatr why = it is=20 different between the piggybacked and the
>separate.
> =
>When=20 the
>receive ignore the No-Response option, it can response by=20 piggybacked
>or
>separated way.
>Why does =
>the draft=20 suppose just to suppress the separate response?   =20
>
>
>And when
>the No-Response works, the ACK = of CON=20 may contain an empty response.
>The
>following process of = the=20 sender side is the same as definitions for
>suppressing =
>separate=20 response. 
>
>The CON/ACK
>is about the = message layer=20 semantics.
>It seems
>that the No-reponse does not touch = the=20 message layer semantics.
>
>Regards,
> =
>Gengyu=20
>WEI
>Network Technology Center
>School of Computer=20
>Beijing University of
>Posts and=20 Telecommunications
>
>
>
>
>From: Rahman, = Akbar=20
>Sent: Sunday, October 18, 2015 8:17 AM
>To: Abhijan = Bhattacharyya=20 ; esko.dijk@philips.com ; cabo@tzi.org ;
>core@ietf.org =
>Subject:=20 Re: [core] New Version Notification for=20
>draft-tcs-coap-no-response-option-12.txt
>=20
>
>
>>Akbar, The reverse
>proxy = consideration have=20 been included as a new section 4.3.
>
>Thanks,=20
>Abhijan.  Looks good.
>
>
>
>One =
>other question, why does the draft say =E2=80=9CExpired=E2=80=9D = at the top =20 even
>though
>the expiry date is April 2016?
>=20
>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12<= BR>>=20
>
>
>From: Abhijan
>Bhattacharyya=20 [mailto:abhijan.bhattacharyya@tcs.com]
>Sent: Thursday, =
>October=20 15, 2015 9:23 AM
>To: esko.dijk@philips.com; cabo@tzi.org;=20
>core@ietf.org; Rahman, Akbar=20
><Akbar.Rahman@InterDigital.com>
>Subject: Fw: New = Version=20
>Notification for = draft-tcs-coap-no-response-option-12.txt
>=20
>Hi Carsten, Esko, Akbar
>and all,
>
>Based = on the=20 recent
>inputs we have shared a new version of the No-Response = draft.=20
>
>
>Esko, I
>have actually removed the = 'Leisure'=20 stuff for unicast. Thought it was
>making
>things a bit=20 complicated.
>
>Akbar, The reverse
>proxy = consideration have=20 been included as a new section 4.3.
>
>
>Carsten,=20
>requesting your suggestion regarding the next step forward.=20
>
>Hoping to see you all
>in Yokohama.=20
>
>Regards
>Abhijan =
>Bhattacharyya
>Associate=20 Consultant
>Scientist, Innovation Lab, Kolkata, =
>India
>Tata=20 Consultancy Services
>Mailto:=20 abhijan.bhattacharyya@tcs.com
>Website:=20
>http://www.tcs.com
>_______________________________________= _____
>Experience=20
>certainty.        IT=20
>Services
>        &= nbsp;           &n= bsp; =20
>Business=20
>Solutions
>        =             &= nbsp; =20
>Consulting
>____________________________________________>
>-----=20
>Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45=20 PM
>-----=20
>
>
>From:       =20
>internet-drafts@ietf.org=20
>
>To:        =
>"Soma=20
>Bandyopadhyay" <soma.bandyopadhyay@tcs.com>,
>"Soma = Bandyopadhyay" <soma.bandyopadhyay@tcs.com>,
>"Abhijan=20 Bhattacharyya" <abhijan.bhattacharyya@tcs.com>,
>"Arpan = Pal"=20 <arpan.pal@tcs.com>,
>"Arpan Pal" = <arpan.pal@tcs.com>,=20
>"Tulika Bose" <tulika.bose@tcs.com>, "Abhijan=20
>Bhattacharyya" <abhijan.bhattacharyya@tcs.com>, =
>"Tulika=20 Bose" <tulika.bose@tcs.com>=20
>Date:        =
>10/15/2015 06:45=20
>PM
>Subject:       =20
>New
>Version Notification for=20 draft-tcs-coap-no-response-option-12.txt=20
>
>
>
>
>
>
>
>
>A= new=20 version of
>I-D, = draft-tcs-coap-no-response-option-12.txt
>has been=20 successfully
>submitted by Tulika Bose and posted to = the
>IETF=20
>repository.
>
>Name:     &nb= sp;           &nbs= p;            = ;   =20
>draft-tcs-coap-no-response-option
>Revision:  &nb= sp;           &nbs= p; =20
>12
>Title:        &= nbsp;           &n= bsp;           &nb= sp;=20
>CoAP option for no server-response
>Document=20
>date:          =       =20
>2015-10-15
>Group:       = ;            =             &= nbsp; =20
>Individual=20
>Submission
>Pages:       = ;            =             &= nbsp; =20
>17
>URL:        &nb= sp;  =20
>https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-o= ptio
>n-12.txt
>Status:      &n= bsp; =20
>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-optio= n/
>Htmlized:      =20
>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12<= BR>>Diff:           =
>https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-op= tion-1
>2
>
>Abstract:
> =20
>There can be M2M scenarios where responses from server=20
>against
>  requests from client might be considered=20 redundant.
>This kind of
>  open-loop exchange (with = no=20 response path from
>the server to the
>  client) may = be=20 desired to minimize resource
>consumption in
>  = constrained=20 systems while simultaneously
>updating a bulk of
>  = resources=20 or updating a resource with a
>very high frequency. = CoAP
> =20 already provides a non-confirmable
>(NON) mode of message=20 exchange
>  where the server end-point
>does not = respond with=20 ACK. However,
>  obeying the
>request/response = semantics, the=20 server end-point
>  responds
>back with a status code=20 indicating "the result of the
>  attempt
>to = understand and=20 satisfy the request".
>
>  This draft =
>introduces a=20 header option for CoAP called 'No-Response'.
> 
>Using = this=20 option the client explicitly tells the server to =
>suppress
> =20 responses against the particular request. This
>option also=20 provides
>  granular control to enable suppression
>of = a=20 particular class or a
>  combination of response-classes.=20
>This option may be effective for
>  both unicast and=20 multicast
>requests. Present draft also discusses
>  = few=20 exemplary
>applications which benefit from this=20
>option.
>
>
>     &nbs= p;     =20
>
>
>
>Please note that it may take a couple of = minutes=20 from the
>time of submission
>until the htmlized version = and diff=20 are available
>at tools.ietf.org.
>
>The IETF=20
>Secretariat
>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D= =3D=3D=3D
>Notice: The=20 information contained in this
>e-mail
>message and/or = attachments=20 to it may contain
>confidential or
>privileged = information. If you=20 are
>not the intended recipient, any
>dissemination, use,=20
>review, distribution, printing or copying of the=20
>
>information contained in this e-mail message =
>and/or=20 attachments to it
>are strictly prohibited. If
>you have = received=20 this communication in error,
>
>please notify us by reply = e-mail or=20 telephone and
>immediately and
>permanently delete the = message=20
>and any attachments. Thank=20
>you
>
>
>______________________________________= _________
>core=20 mailing=20
>list
>core@ietf.org
>https://www.ietf.org/mailman/lis= tinfo/core
>
>
------=_NextPart_000_002F_01D117E3.94CE7B30-- From nobody Thu Nov 5 02:13:07 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F19F1AC3CC for ; Thu, 5 Nov 2015 02:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LRMJUzZjYot for ; Thu, 5 Nov 2015 02:13:04 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4A41AC3E1 for ; Thu, 5 Nov 2015 02:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tA5AD0G7004104 for ; Thu, 5 Nov 2015 11:13:00 +0100 (CET) Received: from dhcp-38-127.meeting.ietf94.jp (t20010c40000030326864e0ee8ff983b4.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:6864:e0ee:8ff9:83b4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ns0zH4XYRz2FfY; Thu, 5 Nov 2015 11:12:59 +0100 (CET) Date: Thu, 5 Nov 2015 19:12:59 +0900 From: Carsten Bormann To: "=?utf-8?Q?core=40ietf.org_WG?=" Message-ID: X-Mailer: Airmail (329) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="563b2bab_51eff623_168ed" Archived-At: Subject: [core] New slide set uploaded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 10:13:06 -0000 --563b2bab_51eff623_168ed Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have uploaded the updated slideset for =46riday: https://www.ietf.org/proceedings/94/slides/slides-94-core-0.pdf We=E2=80=99ll do the security segment first so John can run to his parall= el session in PERC, then do the rest of Tuesday (PATCH, COOL, =46ETCH, Pu= bsub), and then switch back to CoCoA and the mostly-offline nodes. Presenters: Please check that I have your newest version... Gr=C3=BC=C3=9Fe, Carsten --563b2bab_51eff623_168ed Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I believe this is important for the industry as a whole, and that we a= lready have seen considerable deployment experience. Agreed this should be = adopted.

Sent from Outlook




On Sat, Nov 7, 2015 at 1:17 PM -0800, "Juan= Perez" <juanpere@mi= crosoft.com> wrote:

+1

 

It is important for us (at Microsof= t Azure IoT) that this document gets adopted.  Additionally, as part o= f the OMA LWM2M group, it’s important that CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios. 

 

We’ve run tests between world= wide Azure and non-Azure data centers and have found that a UDP keep-alive = is required no more than every 30 seconds in order to maintain reachability between clients and servers. 

 

Thanks,

Juan

 <= /span>

From: Andrew Mcgregor [mailto:andr= ewmcgr@google.com]
Sent: Monday, November 2, 2015 8:38 PM
To: Core <core@ietf.org>
Subject: [core] Call for adoption of draft-tschofenig-core-coap-tcp-= tls

 

The sense of the room at IETF 94 was that we should = adopt this as a working group document.

 

This is the corresponding mailing list call, open un= til November 16.

 

     =   Title           : A TCP and TLS Trans= port for the Constrained Application Protocol (CoAP)
        Authors         : Cars= ten Bormann
                     = ;     Simon Lemay
                     = ;     Valik Solorzano Barboza
                     = ;     Hannes Tschofenig
        Filename        : draft-tsc= hofenig-core-coap-tcp-tls-05.txt
        Pages           := 12
        Date            := 2015-11-02

Abstract:
   The Hypertext Transfer Protocol (HTTP) was designed with TCP a= s the
   underlying transport protocol.  The Constrained Applicati= on Protocol
   (CoAP), while inspired by HTTP, has been defined to make use o= f UDP
   instead of TCP.  Therefore, reliable delivery and a simpl= e 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://data= tracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/

There's also a htmlized version available at:
https://tools.i= etf.org/html/draft-tschofenig-core-coap-tcp-tls-05

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

 

--

Andrew McGre= gor | SRE | andrewmcgr@google.com |<= span style=3D"font-family:"Arial",sans-serif; color:#555555; bord= er:solid #EEB211 1.5pt; padding:2.0pt"> +61 4 1071 2221



-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please 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_E5CA351B4447F7EB8A329087D1E8487699A6CB0D0C477511mailout_-- From nobody Sat Nov 7 17:06:38 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295001B3876 for ; Sat, 7 Nov 2015 17:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laW2zi7m8l0D for ; Sat, 7 Nov 2015 17:06:34 -0800 (PST) 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 245FA1B3139 for ; Sat, 7 Nov 2015 17:06:33 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-ab-563ea0172911 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.2B.29154.710AE365; Sun, 8 Nov 2015 02:06:31 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Sun, 8 Nov 2015 02:06:31 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 79FC74EA98; Sun, 8 Nov 2015 03:06:47 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7E8B14E97E; Sun, 8 Nov 2015 03:06:45 +0200 (EET) To: Zach Shelby , Andrew Mcgregor , Juan Perez , Core References: From: Mohit Sethi Message-ID: <563EA014.10602@ericsson.com> Date: Sun, 8 Nov 2015 10:06:28 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvra74ArswgyN/DS16j81js9j3dj2z ReubXnaLS9eesDuweKyZt4bRY8GmUo8lS34yebTu+MsewBLFZZOSmpNZllqkb5fAlfHx5Vrm gq3SFYseT2ZrYOwR7WLk5JAQMJH4cqCJGcIWk7hwbz1bFyMXh5DAEUaJh88nMkM4Wxkldhzr YoJw1jJKLH/7jQXCmccoMX/SDVaQfmEBb4kn93czgdgiAr2MEn0dshBFnxglpk66xgKSYBPQ k+g8dxxsIa+ApsTnNYvAbBYBFYmNt/eA1YgKREhMnNDAClEjKHFy5hOwOKdAqMTVB3uA6jk4 mAXsJR5sLQMJMwvISzRvnQ31g5rE1XObwGwhAXWJrR0HGCcwCs9CMmkWQvcsJN0LGJlXMYoW pxYX56YbGemlFmUmFxfn5+nlpZZsYgRGwsEtv612MB587niIUYCDUYmHt6DJLkyINbGsuDL3 EKMEB7OSCK+jFlCINyWxsiq1KD++qDQntfgQozQHi5I4bzPTg1AhgfTEktTs1NSC1CKYLBMH p1QDo+Pq+Mc9fMe0e+budTZ/UVVxd3Z3RPJ24ZVRC+2uPV7uwZS5b/VClvSWKddjBI/s370p 7fmc3KOxZsZbG6esOMU++ZoUr3bwzutrHtaWGHWa1H346Fsl/HWjk+5cbYMDsksN065nnms1 vO8qea8m5Fx1YGZzg2zT9ZszClYUpn2Q2b5tQo7/CiWW4oxEQy3mouJEAG5+cumAAgAA Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Nov 2015 01:06:36 -0000 +1. I agree that this is important and should be adopted. /--Mohit On 11/08/2015 09:16 AM, Zach Shelby wrote: > I believe this is important for the industry as a whole, and that we > already have seen considerable deployment experience. Agreed this > should be adopted. > > Sent from Outlook > > > > > On Sat, Nov 7, 2015 at 1:17 PM -0800, "Juan Perez" > > wrote: > > +1 > > It is important for us (at Microsoft Azure IoT) that this document > gets adopted. Additionally, as part of the OMA LWM2M group, it抯 > important that CoAP supports TCP/TLS as a standard to enable > internet/cloud scenarios. > > We抳e run tests between worldwide Azure and non-Azure data centers and > have found that a UDP keep-alive is required no more than every 30 > seconds in order to maintain reachability between clients and servers. > > Thanks, > > Juan > > *From:*Andrew Mcgregor [mailto:andrewmcgr@google.com] > *Sent:* Monday, November 2, 2015 8:38 PM > *To:* Core > *Subject:* [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls > > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > > Andrew McGregor | SRE |andrewmcgr@google.com > | +61 4 1071 2221 > > > ------------------------------------------------------------------------ > > -- IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please 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. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Sat Nov 7 17:40:35 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C756B1A6F30 for ; Sat, 7 Nov 2015 17:40:34 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s3eWiNzge83 for ; Sat, 7 Nov 2015 17:40:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8741A6FD0 for ; Sat, 7 Nov 2015 17:40:31 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gc355804@ohio.edu; Received: from [192.168.0.3] (75.118.191.143) by BN3PR01MB1383.prod.exchangelabs.com (10.163.36.150) with Microsoft SMTP Server (TLS) id 15.1.318.15; Sun, 8 Nov 2015 01:40:29 +0000 To: References: <563EA014.10602@ericsson.com> From: Gilbert Clark Message-ID: <563EA806.3030205@ohio.edu> Date: Sat, 7 Nov 2015 20:40:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563EA014.10602@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [75.118.191.143] X-ClientProxiedBy: BY2PR16CA0001.namprd16.prod.outlook.com (25.164.126.139) To BN3PR01MB1383.prod.exchangelabs.com (25.163.36.150) X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1383; 2:B73cZ0ACfGvkWZ1B6nj1x3AuX5gPk1q5fP3wghRJ9MIps/3ef5e6DCXGbtcb63yCriPMjfozL3tC6AanwJAO1+wkJYYpktdTSpjf/Zu9WCB36e0LMCOgHbpZ4JQFZyppuPGergFDSkz8SjpWhQx/FS4ozwXHeVUERxe+os3UfvY=; 3:FbEuVpHjxLNJTa2l5DWWKwc0E1Fjs5C+wdEXI5lddwFTE4Jzn3gGqazo7b5rWOMJYjBjGTr9HpE9fNnBwAez3oKk9mnJhvaSp/Y8lgfik6ValSLMCig4e7XUejQ/oBtv0zsJbjpOEGivBSp6P9i2dA==; 25:GhuFD/C/G7AMM7g/O2N5GOvlZijfU721k8srNuJm9QGubiUo216iMwBJtfgH/DcSevN2WXoTWgXadvfmeHzrR4Qvop6XTYW9b2q2Cbap/pBy22X88rb78CaMFqK0tbrDdiahidprwzsyTPgvaVwVbJVioCS09Qd8ECtxHWCfnzAUekqa4aPKIZVD8cedfFjJmZKnRXpPOFwF/SkBrUsQCPAimaAH7YSrs2w/T3KONm2oxMrl5LIS9tFTAEidG/6gxKekgBogIsbDmPugO1q8DQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR01MB1383; X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1383; 20:UwNMDaL5nl2vzEGyJHceIBsMlL5A1O63buO3ueORhUszl8/j4k9l+qKNT+JRQd0Tn0Yv1Bn0PBr+nd8ND1v3zCpAiJ2ilvojiT9cPIwXO+g7nGmMaleatdOBG6k0U4/yngKltWNDWQlwwVrLymCAyyEtETc0zMSQ/lhvqQ/s8IO5kIdWrqd0+8FwKtc1+eZeJHiwmyv1sZdsnOxNvjCaaYtfDKTmbmNAtnI6qV658BAT7aYPvj08/4nXO0e1UIHGR5lBp6ZNtXtl7sbexfZFJas1S79x6IuZRONI7V4ST/sTnG5UA3Nqs6RtV7aGngRxmd6o0FhhWmwB8nzrEJgqQjiQIGXqUevvUkIJYkGC21WDb+C3b1HSvqgv16gmBUc0hrrKFuBqeWf+w4LSVFR+oYbdrzoV+U+R0sMYDyTSzPgDthAB87yPbVpXval12Y0yT0fHu25cQsS8DLdu8s4ozeQEhz02xivr5cliBPM4x1LM4VCS2q/HnCL/MVSCCsgx; 4:CXnSM73gPcMJ5E632uKZiet1oOTvLbs3NoaY2xDaEB0Qnl5MZmILox2q9iIv2ojorrpTFT+c6zHqNyGnkJ8Qj79bGb6sj1C1WVjimBl4SjhUK+Mf0Hs+reA/oOyu2B4SPiRdA57iADiJkvAkqxajyOnsrDqErLAuJmf+JFxHXy7HjmE3NCoWKrtK3yFr/l5myg0D/8neIcdttiVhLE593jmvBP7FJw+NV1dTxHO6MJDV2oCbTxZRXgTp80Zy5qEOGfQdjmndh88VjBNqDPOI6sp6W4HoIaneQ7jnTGHzL9i8gwAWua9HDIk0AjEg4HXO6FIXRZPWgaF3uRQBcjW66fEQdjkg9Q9ieMwd6VyDV53wlBX2HfeYgPbEYgO6Wopj X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(211936372134217)(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR01MB1383; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB1383; X-Forefront-PRVS: 0754F7E325 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(164054003)(189002)(377454003)(377424004)(479174004)(199003)(24454002)(92566002)(4001350100001)(88552001)(230783001)(42186005)(2351001)(66066001)(15975445007)(93886004)(59896002)(5008740100001)(122386002)(117156001)(80316001)(83506001)(89122001)(47776003)(65806001)(19580395003)(15198665003)(15395725005)(19580405001)(5890100001)(65956001)(40100003)(2950100001)(64126003)(23746002)(77096005)(36756003)(110136002)(75432002)(50986999)(107886002)(76176999)(87266999)(33656002)(450100001)(50466002)(105586002)(54356999)(97736004)(189998001)(5004730100002)(101416001)(5007970100001)(5001960100002)(86362001)(87976001)(81156007)(106356001)(65816999)(90282001)(42262002)(10090945008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1383; H:[192.168.0.3]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ohio.edu does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BN3PR01MB1383; 23:CtsDHcj/x6j/r1NbS6ZD4u5oAw/CPUIHx1LOp?= =?Windows-1252?Q?qzrEZFFTsk478xGsP8TYsDxDnjjU18nHMhRKF7mVdGZq1YkRLywtfgBu?= =?Windows-1252?Q?Q7tKppXDsg1pzHGC9rzp5uWyukdUYz5j/kd0qB/66lX+DmlrB++cGqVN?= =?Windows-1252?Q?OaCV91ULewTsylMpSpXeWjGkbfeQ7+8DJDi1stKg4P9nm/SOa+JV0k2X?= =?Windows-1252?Q?sd7YCr4xEme7VOteC9xYcOEAqBxAM+BAheoW8n5eQivNUnz9PEYB6nZt?= =?Windows-1252?Q?FfV48vHSRq7zcOY3tIeFq8Ew4mn46NVvp0zRaeUFr+GdGx2pIt+tsDje?= =?Windows-1252?Q?G2DOPlHd56a/MKeA6fmx3Pr5iB2XfUyrXW36EalZSoFOD+kVswoSSXgx?= =?Windows-1252?Q?li4UUXvTN+xXzqsoGJ6wcfI9QP2+Tt2n+MWvsoeYAjfsxdI/ijMQ061K?= =?Windows-1252?Q?GqoEo8T0NvJDwe3SGkJOWSsXwlOCcXltQ5MIA/Ga6bnI65/3A7b7shEm?= =?Windows-1252?Q?Moi2Dc21EHQCWcN082BuOyxzR6VJ+f2DzPG+Y990vVKI8rdtuLord9Ue?= =?Windows-1252?Q?VjDaVNG6A9wmtttGwK0HvMOzGvPYDhIxXhfhXpYzub5zKaTT0uf1X8IT?= =?Windows-1252?Q?jbW327sFi0pa2UPkDc6Zeq1gQSwNMVUqCMPVoZOp9tNjvraU9car62Py?= =?Windows-1252?Q?QKly4HoXjDNi/nO7U2Wnk1T2nxHOx4P+pw8n7qnfChUibqSPkX9LNDza?= =?Windows-1252?Q?LAkPjKDqOgDL1M2N6V0PfOrG4jjSrLGGGNWz2BAZ7khug/oUkG4J7vzl?= =?Windows-1252?Q?Hprnm9KykdZi3lnsINx1tQNTRu4WFG2JQOcWEu8iJaqgCGMXEjgN/dvn?= =?Windows-1252?Q?3lxw5MdUeyAIK/DwtnbeMVwb//lccHbQQAXkKkoEWweYthTq4B9WNoRy?= =?Windows-1252?Q?DbvtTnRs46eAj1pcmjBpWUQg67HtalcCpCXy+nToPScsnhBrKOHwMYdP?= =?Windows-1252?Q?YujLmmK1E9WAA5aLdOo5WswrTBjHDJPkD+hUN/OBmx7AE1Eby+TEye2Q?= =?Windows-1252?Q?V6oiMV8KjUssJJlJJtBDA92eWqiPUm9prc7QD6H5jGPscfQwUfM/U613?= =?Windows-1252?Q?JGC1c4vuL1gARp9B/BfmWTktv7HQPi1zQ1BH/INiFEwIDwMUXabrNFZN?= =?Windows-1252?Q?QeY3pdSySMl3mHUpEJ9XjrWeDCvECR0sMuMkegMsLenyB4f2tD5hURlS?= =?Windows-1252?Q?jGXOueB5EPKgloK2rYV1ijL4Ao7sv961deGNzwmBfs2vaiqHl56q2PyP?= =?Windows-1252?Q?/mW3tGsKrouITTtzMgU+iKVX5fUuARgLLNY9gTsRD7NQZsVxGfWes3/m?= =?Windows-1252?Q?GX3qPBKWLFe9P2jvafi8SaFl319u+jX6siGtG4Uv49WzmXTO80iur+8z?= =?Windows-1252?Q?4du0ZILVp9+ZIii3xAyUmExQEZ2C5gimOwFr5XZ3uZr2LFZ8tziPLNnN?= =?Windows-1252?Q?jXQjXxi0aqigAg/luRV4MaS20OMS00gPCKj858T3lAH1KPO+cBJ6z1CU?= =?Windows-1252?Q?4bLma/tTHYyG424w/uKnivY7ZW0bu9c+bibpmRfLuD9ulowgZU1/al2w?= =?Windows-1252?Q?fL2XWIf4Bg4EK/ddGrYyOlwCRzb6TvKPvCB5/u9kOp+0AxX+Vs9vVuKc?= =?Windows-1252?Q?Seu9K8niWN3wYpYGQQFJThAKtHVQHYUfBcdebjVbkUPpqV17YqNkN+kg?= =?Windows-1252?Q?bMjx02mTewhfwwzG1LqD1PWl6TYPefSfXLTHYw=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1383; 5:+SdPTMQD3vFjxHPTxW+tasz2XvjepbTl6vtPiHhXRGBJvvNFvJZ7ulkuJ6IiHmZ5l1BT2GG/+TXwE0yZ9S+gChQoif69g93rg28UE536WxWsk3O3MeYmgtbZqon87PnPgxfez5nsXiDTysrILgAobg==; 24:oVy1eo1pswtfvRPYCsPAng0R3PgeV66Yb6dj8etp/4AGkQjkirSPnUe8+ruH4XrxOOlrs7lnUt3aviLCM3SngXsEKieO5PE1ErqXzrOVAG8=; 20:ysD7sgpvZcisFGfIgdSLEBZKXIIrUr9sDvcUM27CC5OfwGRqMffB9qJbnpRN3fcoIHoCeX/ftdIrks3216l1DA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: ohio.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2015 01:40:29.2474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1383 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Nov 2015 01:40:34 -0000 +1 vote for adoption -Gilbert Clark On 11/7/2015 8:06 PM, Mohit Sethi wrote: > +1. I agree that this is important and should be adopted. > > /--Mohit > > On 11/08/2015 09:16 AM, Zach Shelby wrote: >> I believe this is important for the industry as a whole, and that we >> already have seen considerable deployment experience. Agreed this >> should be adopted. >> >> Sent from Outlook >> >> >> >> >> On Sat, Nov 7, 2015 at 1:17 PM -0800, "Juan Perez" >> > wrote: >> >> +1 >> >> It is important for us (at Microsoft Azure IoT) that this document >> gets adopted. Additionally, as part of the OMA LWM2M group, it抯 >> important that CoAP supports TCP/TLS as a standard to enable >> internet/cloud scenarios. >> >> We抳e run tests between worldwide Azure and non-Azure data centers >> and have found that a UDP keep-alive is required no more than every >> 30 seconds in order to maintain reachability between clients and >> servers. >> >> Thanks, >> >> Juan >> >> *From:*Andrew Mcgregor [mailto:andrewmcgr@google.com] >> *Sent:* Monday, November 2, 2015 8:38 PM >> *To:* Core >> *Subject:* [core] Call for adoption of >> draft-tschofenig-core-coap-tcp-tls >> >> The sense of the room at IETF 94 was that we should adopt this as a >> working group document. >> >> This is the corresponding mailing list call, open until November 16. >> >> Title : A TCP and TLS Transport for the Constrained >> Application Protocol (CoAP) >> Authors : Carsten Bormann >> Simon Lemay >> Valik Solorzano Barboza >> Hannes Tschofenig >> Filename : draft-tschofenig-core-coap-tcp-tls-05.txt >> Pages : 12 >> Date : 2015-11-02 >> >> 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-tschofenig-core-coap-tcp-tls/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 >> >> -- >> >> Andrew McGregor | SRE |andrewmcgr@google.com >> | +61 4 1071 2221 >> >> >> ------------------------------------------------------------------------ >> >> -- IMPORTANT NOTICE: The contents of this email and any attachments >> are confidential and may also be privileged. If you are not the >> intended recipient, please 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. >> >> >> _______________________________________________ >> 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 Sat Nov 7 18:39:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AE71ACE90 for ; Sat, 7 Nov 2015 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.248 X-Spam-Level: X-Spam-Status: No, score=-0.248 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, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddtdR8B7nVux for ; Sat, 7 Nov 2015 18:39:10 -0800 (PST) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id BE8321ACE8B for ; Sat, 7 Nov 2015 18:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446950347; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=nFhEbyNfAJdFSvE/2V+ozAmtwCrxR+E9BDX9szguYNE=; b=mrvaGhMQ8HRf1sGCSpGbXV0PbjLZ7wT9MiUV/CYLly3Scu8v9ENSFQHzW5pn0DqylMW7rfeHsmQKMY46j1YJRmfgE7DiBDJU2EQR/EKsxX7sY92RiNz+93kHGfxhbfxkCYXxk4JZ38d7aymLI7Sm1TZoeSL1+ja2a7SsT0hEDbI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03286; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.35.196(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sun, 08 Nov 2015 10:39:02 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 08 Nov 2015 10:38:51 +0800 From: "Kepeng Li" To: Andrew Mcgregor , Core Message-ID: Thread-Topic: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3529827542_87250" Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Nov 2015 02:39:13 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3529827542_87250 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable +1 for adoption. Kind Regards Kepeng =B7=A2=BC=FE=C8=CB: Andrew Mcgregor =C8=D5=C6=DA: Tuesday, 3 November, 2015 1:38 pm =D6=C1: Core =D6=F7=CC=E2: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls The sense of the room at IETF 94 was that we should adopt this as a working group document. This is the corresponding mailing list call, open until November 16. Title : A TCP and TLS Transport for the Constrained Application Protocol (CoAP) Authors : Carsten Bormann Simon Lemay Valik Solorzano Barboza Hannes Tschofenig Filename : draft-tschofenig-core-coap-tcp-tls-05.txt Pages : 12 Date : 2015-11-02 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-tschofenig-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-05 --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --B_3529827542_87250 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
+1 for adoption.

<= /div>
Kind Regards
Kepeng

=B7=A2=BC=FE=C8=CB: Andrew Mcgregor <andrewmcgr@google.com>
=C8= =D5=C6=DA: Tuesday, 3 November, 2015 1:38 pm
=D6=C1: Core <core@ietf.org&g= t;
=D6=F7=CC=E2: [core] Call for adoption = of draft-tschofenig-core-coap-tcp-tls

The sense of the room at IETF 94 was that we should adopt this as a working= group document.

This is the corresponding mailing list c= all, open until November 16.

        Title         =  : A TCP and TLS Transport for the Constrained Application Protocol (C= oAP)
 = ;       Authors         : Carsten Bo= rmann
&nbs= p;                     &nb= sp;   Simon Lemay
                  =         Valik Solorzano Barboza
         =                 Hannes Tschofenig
  &nbs= p;     Filename        : draft-tschofenig-core= -coap-tcp-tls-05.txt
       = Pages           : 12
        Date&n= bsp;           : 2015-11-02

Abst= ract:
&nbs= p;  The Hypertext Transfer Protocol (HTTP) was designed with TCP as the=
  &n= bsp;underlying transport protocol.  The Constrained Application Protoco= l
  &= nbsp;(CoAP), while inspired by HTTP, has been defined to make use of UDP
   = instead of TCP.  Therefore, reliable delivery and a simple congestion
  &nbs= p;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 a= s 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 i= s:
https://datatracker.ietf.org/doc/draft-tschofenig-cor= e-coap-tcp-tls/

There's also a htmlized version available at= :
https://tools.ietf.org/html/draft-tschofenig-core-coap-tc= p-tls-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-cor= e-coap-tcp-tls-05

--
Andrew McGregor | SRE | andrewmcgr@google.com=  | +61 4 1071 22= 21
_______________________________________________ core mailing list core@ietf.org https://www.ietf.org/m= ailman/listinfo/core --B_3529827542_87250-- From nobody Sat Nov 7 23:14:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342DF1A884C for ; Sat, 7 Nov 2015 23:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh_2LMbzxc9i for ; Sat, 7 Nov 2015 23:14:45 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 C77501A8847 for ; Sat, 7 Nov 2015 23:14:44 -0800 (PST) Received: by wicll6 with SMTP id ll6so52581239wic.0 for ; Sat, 07 Nov 2015 23:14:43 -0800 (PST) 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 :content-type; bh=5pBA0bfUXf+J6Lh2li2UFC26zxmYotyBpuXYY1TRB/A=; b=OkYJQ+9Ua0EO9jy8W3Ug0pFxrW4mxv5FLoPjzqOjgjnvCykLpSfgkSj4Rx/VPAWgQO KAwaCbxWDuENCjGJBPYrjt/0r5jzoRmGSN9hpfORbB6SGI2GJcc8mE7O4Xw76XU18eIH mDLRcrF1TLYRRDcn8AhqNPZs9LHh935iLKtkU/1WGJ5vX8L0LPdMKZCi1H4DE9ZIGBpO 1oeE3HwR14NCwfioWQXroRZnQrUeJ0nkwlgMOt1z4aauGRoHI+hYRKYCbQ2RVT6MzUJz sN1aAg9KP2BIABDJGFczc76yVgh8pAmSdr8e8H9JAYXP0AfSxTlkHGBzM3FZrAclCxNR kyPQ== X-Received: by 10.194.84.42 with SMTP id v10mr24298532wjy.116.1446966883378; Sat, 07 Nov 2015 23:14:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Julien Vermillard Date: Sun, 08 Nov 2015 07:14:33 +0000 Message-ID: To: Core Content-Type: multipart/alternative; boundary=047d7beba1da15ef200524023bc3 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Nov 2015 07:14:47 -0000 --047d7beba1da15ef200524023bc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 We suffer the same issues between our servers and our cellular modems. On some network we need to go down to 20 seconds. Julien Le sam. 7 nov. 2015 22:17, Juan Perez a =C3=A9crit= : > +1 > > > > It is important for us (at Microsoft Azure IoT) that this document gets > adopted. Additionally, as part of the OMA LWM2M group, it=E2=80=99s impo= rtant that > CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios. > > > > We=E2=80=99ve run tests between worldwide Azure and non-Azure data center= s and > have found that a UDP keep-alive is required no more than every 30 second= s > in order to maintain reachability between clients and servers. > > > > Thanks, > > Juan > > > > *From:* Andrew Mcgregor [mailto:andrewmcgr@google.com] > *Sent:* Monday, November 2, 2015 8:38 PM > *To:* Core > *Subject:* [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls > > > > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > > > This is the corresponding mailing list call, open until November 16. > > > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-05 > > > > -- > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --047d7beba1da15ef200524023bc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1=C2=A0

We suffer the same issues between our servers and our cellul= ar modems.
On some network we need to go down to 20 seconds.

Julien


Le=C2=A0sam. 7 nov. 2015 22= :17,=C2=A0Juan Perez <juanpere= @microsoft.com> a =C3=A9crit=C2=A0:

+1

=C2=A0

It is important for us (at Microsoft = Azure IoT) that this document gets adopted.=C2=A0 Additionally, as part of = the OMA LWM2M group, it=E2=80=99s important that CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios.=C2=A0 =

=C2=A0

We=E2=80=99ve run tests between world= wide Azure and non-Azure data centers and have found that a UDP keep-alive = is required no more than every 30 seconds in order to maintain reachability between clients and servers.=C2=A0

=C2=A0

Thanks,

Juan

=C2=A0

From: Andrew Mcgregor [mailto:andrewmcgr@google.com<= /a>]
Sent: Monday, November 2, 2015 8:38 PM
To: Core <core= @ietf.org>
Subject: [core] Call for adoption of draft-tschofenig-core-coap-tcp-= tls

=C2=A0

The sense of the room at IETF 94 was that we should = adopt this as a working group document.

=C2=A0

This is the corresponding mailing list call, open un= til November 16.

=C2=A0

=C2=A0 =C2=A0 =C2=A0= =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A TCP and TLS Trans= port for the Constrained Application Protocol (CoAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cars= ten Bormann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Simon Lemay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Valik Solorzano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tsc= hofenig-core-coap-tcp-tls-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-11-02

Abstract:
=C2=A0 =C2=A0The Hypertext Transfer Protocol (HTTP) was designed with TCP a= s the
=C2=A0 =C2=A0underlying transport protocol.=C2=A0 The Constrained Applicati= on Protocol
=C2=A0 =C2=A0(CoAP), while inspired by HTTP, has been defined to make use o= f UDP
=C2=A0 =C2=A0instead of TCP.=C2=A0 Therefore, reliable delivery and a simpl= e congestion
=C2=A0 =C2=A0control and flow control mechanism are provided by the message= layer
=C2=A0 =C2=A0of the CoAP protocol.

=C2=A0 =C2=A0A number of environments benefit from the use of CoAP directly= over a
=C2=A0 =C2=A0reliable byte stream such as TCP, which already provides these=
=C2=A0 =C2=A0services.=C2=A0 This document defines the use of CoAP over TCP= as well as
=C2=A0 =C2=A0CoAP over TLS.


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

There's also a htmlized version available at:
https://tools.i= etf.org/html/draft-tschofenig-core-coap-tcp-tls-05

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

=C2=A0

--

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--047d7beba1da15ef200524023bc3-- From nobody Sat Nov 7 23:24:56 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9E21A8895 for ; Sat, 7 Nov 2015 23:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIoPsfFhOyfo for ; Sat, 7 Nov 2015 23:24:52 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 B0C271A8894 for ; Sat, 7 Nov 2015 23:24:51 -0800 (PST) Received: by lbblt2 with SMTP id lt2so61964991lbb.3 for ; Sat, 07 Nov 2015 23:24:49 -0800 (PST) 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 :content-type; bh=oxGKisXX83WZkgVxMvHJvF58OfWG9ayQy/A1GNcF1Rg=; b=0jZaxsk+RdXsaomp0Th5TQfMn6tui1RPGTNpyW++bsiomPaz7QqmuVBFLtfha7FBvo 2QpANCZjysg6jaG6cX0+6qG/k+06swToYCE5OodF2owQllM/+fSq9Itsuu7EZhxLUSFD uTI+RmYn+DUaenqQ6ZO0RciJsxZ4R83+U7VrZ+gN4+Kfs9WMLBqTmSb0TCLndQeL0ywC dTXisZvDDeSbAZKUvIc0jMzHso+umlTvHvdfQROFZ6sTD6rRdf/WwfSnaoXz1QbAzeXA m3ZVgyaKtIrqz7S87rM8sU6/aYJVwIslbq+wak1RbGJdil1Ch33NEVY8KJw03z6ZcXF2 2VnQ== X-Received: by 10.112.172.138 with SMTP id bc10mr10880890lbc.74.1446967489816; Sat, 07 Nov 2015 23:24:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Wojciech Bober Date: Sun, 08 Nov 2015 07:24:40 +0000 Message-ID: To: Julien Vermillard , Core Content-Type: multipart/alternative; boundary=001a11c267143b6e350524025f03 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 08 Nov 2015 07:24:54 -0000 --001a11c267143b6e350524025f03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Same experience as Julien's with even lower (10s) periods on some networks in Poland. niedz., 8.11.2015, 08:14 Julien Vermillard u=C5=BCytkownik napisa=C5=82: > +1 > > We suffer the same issues between our servers and our cellular modems. > On some network we need to go down to 20 seconds. > > Julien > > Le sam. 7 nov. 2015 22:17, Juan Perez a =C3=A9cr= it : > >> +1 >> >> >> >> It is important for us (at Microsoft Azure IoT) that this document gets >> adopted. Additionally, as part of the OMA LWM2M group, it=E2=80=99s imp= ortant that >> CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios. >> >> >> >> We=E2=80=99ve run tests between worldwide Azure and non-Azure data cente= rs and >> have found that a UDP keep-alive is required no more than every 30 secon= ds >> in order to maintain reachability between clients and servers. >> >> >> >> Thanks, >> >> Juan >> >> >> >> *From:* Andrew Mcgregor [mailto:andrewmcgr@google.com] >> *Sent:* Monday, November 2, 2015 8:38 PM >> *To:* Core >> *Subject:* [core] Call for adoption of draft-tschofenig-core-coap-tcp-tl= s >> >> >> >> The sense of the room at IETF 94 was that we should adopt this as a >> working group document. >> >> >> >> This is the corresponding mailing list call, open until November 16. >> >> >> >> Title : A TCP and TLS Transport for the Constrained >> Application Protocol (CoAP) >> Authors : Carsten Bormann >> Simon Lemay >> Valik Solorzano Barboza >> Hannes Tschofenig >> Filename : draft-tschofenig-core-coap-tcp-tls-05.txt >> Pages : 12 >> Date : 2015-11-02 >> >> 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-tschofenig-core-coap-tcp-tls/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-0= 5 >> >> >> >> -- >> >> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 >> _______________________________________________ >> 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 > --001a11c267143b6e350524025f03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

Same experience as Julien's with even lower (10s) period= s on some networks in Poland.


niedz., 8.11.2015, 08:14=C2= =A0Julien Vermillard u=C5=BCytkownik <jvermillard@gmail.com> napisa=C5=82:

+1=C2=A0

We suffer the same issues between our servers and our cellul= ar modems.
On some network we need to go down to 20 seconds.

Julien


Le=C2=A0sam. 7 nov. 2015 22= :17,=C2=A0Juan Perez <juanpere@microsoft.com> a =C3=A9crit=C2=A0:

+1

=C2=A0

It is important for us (at Microsoft = Azure IoT) that this document gets adopted.=C2=A0 Additionally, as part of = the OMA LWM2M group, it=E2=80=99s important that CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios.=C2=A0 =

=C2=A0

We=E2=80=99ve run tests between world= wide Azure and non-Azure data centers and have found that a UDP keep-alive = is required no more than every 30 seconds in order to maintain reachability between clients and servers.=C2=A0

=C2=A0

Thanks,

Juan

=C2=A0<= /p>

From: Andrew Mcgregor [mailto:andrewmcgr@google.com<= /a>]
Sent: Monday, November 2, 2015 8:38 PM
To: Core <core= @ietf.org>
Subject: [core] Call for adoption of draft-tschofenig-core-coap-tcp-= tls

=C2=A0

The sense of the room at IETF 94 was that we should = adopt this as a working group document.

=C2=A0

This is the corresponding mailing list call, open un= til November 16.

=C2=A0

=C2=A0 =C2=A0 =C2=A0= =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A TCP and TLS Trans= port for the Constrained Application Protocol (CoAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cars= ten Bormann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Simon Lemay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Valik Solorzano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tsc= hofenig-core-coap-tcp-tls-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-11-02

Abstract:
=C2=A0 =C2=A0The Hypertext Transfer Protocol (HTTP) was designed with TCP a= s the
=C2=A0 =C2=A0underlying transport protocol.=C2=A0 The Constrained Applicati= on Protocol
=C2=A0 =C2=A0(CoAP), while inspired by HTTP, has been defined to make use o= f UDP
=C2=A0 =C2=A0instead of TCP.=C2=A0 Therefore, reliable delivery and a simpl= e congestion
=C2=A0 =C2=A0control and flow control mechanism are provided by the message= layer
=C2=A0 =C2=A0of the CoAP protocol.

=C2=A0 =C2=A0A number of environments benefit from the use of CoAP directly= over a
=C2=A0 =C2=A0reliable byte stream such as TCP, which already provides these=
=C2=A0 =C2=A0services.=C2=A0 This document defines the use of CoAP over TCP= as well as
=C2=A0 =C2=A0CoAP over TLS.


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

There's also a htmlized version available at:
https://tools.i= etf.org/html/draft-tschofenig-core-coap-tcp-tls-05

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

=C2=A0

--

_______________________________________________
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
--001a11c267143b6e350524025f03-- From nobody Sun Nov 8 15:07:47 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE0B1B4B0D for ; Sun, 8 Nov 2015 15:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxemSdr9UutL for ; Sun, 8 Nov 2015 15:07:44 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA2251B4B0B for ; Sun, 8 Nov 2015 15:07:43 -0800 (PST) Received: by ykfs79 with SMTP id s79so10123772ykf.1 for ; Sun, 08 Nov 2015 15:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A1messjq5kCtvcuKHuCFDgVeyraI4m729jqo6TxU9tI=; b=vnishCcHR/OgndlC/pnMyuFUPfdWpxk/LkH0WZOnW3IyNoXpSAx9zAH8joZdVs9i0H VbAvLmQFCz/eC0SmPOLnb1ZNuCvNq2oGFrfJoHIQkSUxr7fdfEX6NHukuYLLWcCmDv5E qY4J586qlVJyRF5E014/uhA6HxZ1ydru1AOS249PbTbit18gzktl1nNUipRTlssM8fON ZsPXBBUeeP4fbDWbzw2G7Ps+rafqeux4uioW19TM/FzdgTfTldYnlB9fna495sViMAVm HxYqb5rvOJgTffDsTZDMbPGxJJ9ogh86TH3z5cHmE24CFeWTprBpxCWEOA1XII31tzhW YuSg== MIME-Version: 1.0 X-Received: by 10.13.249.5 with SMTP id j5mr20381512ywf.146.1447024063138; Sun, 08 Nov 2015 15:07:43 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.31.8.67 with HTTP; Sun, 8 Nov 2015 15:07:43 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Nov 2015 23:07:43 +0000 X-Google-Sender-Auth: TDKME-5EIEtiWoLEVxI8BNtNV-k Message-ID: From: Robert Cragie To: Andrew Mcgregor Content-Type: multipart/alternative; boundary=94eb2c0b4d3643d3e705240f8bd7 Archived-At: Cc: Core Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 23:07:45 -0000 --94eb2c0b4d3643d3e705240f8bd7 Content-Type: text/plain; charset=UTF-8 +1 - I fully support adoption of this document. Robert On 3 November 2015 at 04:38, Andrew Mcgregor wrote: > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --94eb2c0b4d3643d3e705240f8bd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 - I fully support adoption of this document.

Robert

On 3 November 2015 at 04:38, Andrew Mcgregor &l= t;andrewmcgr@goo= gle.com> wrote:
The sense of the room at IETF 94 was that we should adopt this as a w= orking group document.

This is the corresponding mailing= list call, open until November 16.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: A TCP and TLS Transport for the Constrained Applicati= on Protocol (CoAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Carsten Bormann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Simon Lemay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Valik Solorz= ano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tschofenig-core-coap-tcp-tls-05.txt
<= span style=3D"font-size:12.8px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-11-02

Abst= ract:
=C2=A0 =C2=A0The Hypertext Transfer Protocol (HTTP) was designed with TCP = as the
=C2=A0 =C2=A0underlying transport protocol.=C2=A0 The Constrained Applica= tion Protocol
=C2=A0 =C2=A0(CoAP), while inspired by HTTP, has been defined to m= ake use of UDP
=C2=A0 =C2=A0instead of TCP.=C2=A0 Therefore, reliable delivery a= nd a simple congestion
=C2=A0 =C2=A0control and flow control mechanism are provi= ded by the message layer
=C2=A0 =C2=A0of the CoAP protocol.

=C2=A0 =C2=A0A number of environments benefit from the use of CoAP = directly over a
=C2=A0 =C2=A0reliable byte stream such as TCP, which already pro= vides these
=C2=A0 =C2=A0services.=C2=A0 This document defines the use of CoAP o= ver TCP as well as
=C2=A0 =C2=A0CoAP over TLS.


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

There's also a htmliz= ed version available at:
https://tools.ietf.or= g/html/draft-tschofenig-core-coap-tcp-tls-05

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

--
Andrew McGregor=C2=A0|=C2=A0SRE=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221

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


--94eb2c0b4d3643d3e705240f8bd7-- From nobody Sun Nov 8 18:10:53 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8140A1A8864 for ; Sun, 8 Nov 2015 18:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdhbZWw-AbtE for ; Sun, 8 Nov 2015 18:10:47 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 250C11A6F62 for ; Sun, 8 Nov 2015 18:10:45 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 7B6B219F978 for ; Mon, 9 Nov 2015 10:10:43 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.240.213]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5429D19F5D6; Mon, 9 Nov 2015 10:10:42 +0800 (HKT) Message-ID: <32B1165DE0624F1CB09386E53B67C252@WeiGengyuPC> From: "weigengyu" To: , "Oliver Kleine" References: <563CAA84.7070706@itm.uni-luebeck.de> <563CEFE5.1010101@itm.uni-luebeck.de> In-Reply-To: Date: Mon, 9 Nov 2015 10:10:43 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D11AD6.E4C42B80" 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] ack message format in confirmable notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 02:10:51 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0042_01D11AD6.E4C42B80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Robert and Oliver,=20 By RFC7252, the ACK with Empty resopnse of CON should be 4 byte.=20 It is a malformed packet if the token length is not ZERO when an ACK = message with Empty response. =20 But, there were arguments to have the Empty response with the token of = request which is in preceeding.=20 Some implementations accept the empty response with token (the ACK = message sige > 4) is rational,=20 as it is easy to directly match the request and the response.=20 If an ACK with ZERO token lenth is received, for matching the request = and response the sender needs to keep the mapping of request token and = the message ID.=20 After receiving an ACK with ZERO token length, the sender expects and = waits for a separate response of the request token.=20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Robert Cragie=20 Sent: Saturday, November 07, 2015 5:40 AM To: Oliver Kleine=20 Cc: mailto:core@ietf.org=20 Subject: Re: [core] ack message format in confirmable notifications I think implementations should really drop messages with Empty code = where the token length is not equal to 0 or the message size is not 4 = bytes. However, I guess it depends what you mean by "accept and proceed" = in the context of dropping messages. As long as the semantic meaning of = the Empty code is processed, then it won't "proceed" much anyway so = whether there is any additional token or even payload is probably moot.=20 Note the robustness principle is not about handling malformed packets. = It is about handling valid packets formed in a way you wouldn't send = yourself. Malformed (i.e. invalid) packets must be dropped and typically = at the first point of parsing where it is considered malformed. Robert On 6 November 2015 at 18:22, Oliver Kleine = wrote: Hi Matthieu, some implementations (maybe most of them) accept and proceed empty = messages with a token length > 0 (and ignore the token, if any). This is to follow Postels robustness principle (from RFC 793): "Be = conservative in what you do, be liberal in what you accept from = others.", i.e. do not (knowingly) send malformed messages but be = prepared to receive and handle malformed messages from others. Best, Oliver On 06.11.2015 15:01, Matthieu Vial wrote: Hi Oliver, Thanks for your answer. As I understand your comment, a token length>0 in a notification ack = is malformed but most implementations just don't care. It seems like = even if the RFC says the length MUST be 0 most implement it as SHOULD be = 0. Is that right ? BR, Matthieu On Fri, Nov 6, 2015 at 2:26 PM, Oliver Kleine = > wrote: Hello Matthieu, according to section 1.2 of RFC 7252 an empty message only = contains the 4-byte header. The token length is a part of the header, the token itself is not. This implies a token length of 0 for empty messages just because there is no room left for a token of = length > 0. Thus, empty messages with token length > 0 may be considered malformed, as a token length > 0 implies a message larger than 4 = byte. Furthermore, on the "semantic" level, there is a difference = between a token of length 0 in empty and non-empty messages. In = non-empty messages the token (incl. the one of size 0) is basically used = to relate requests and responses to each other (see [1] for the = plugtests). This does not hold for empty messages. In empty messages, the = token has no semantic meaning at all. I guess, that's why there is no plugtest to check for token lengths in empty messages. Best regards, Oliver [1] http://rawgit.com/cabo/td-coap3/master/base.html (CORE_10, = 11, 12) On 06.11.2015 09:22, Matthieu Vial wrote: Hi all, There is no example of confirmable notification in RFC7641 = and I would like to clarify the format of the ack message sent by the = coap client. Basically, an ack message to a confirmable notification has = no content and no REST semantics so the code is 0.00. According to https://tools.ietf.org/html/rfc7252#section-3: "As a special case, Code 0.00 indicates an Empty message." So this message should be an empty message. According to https://tools.ietf.org/html/rfc7252#section-4.1 = an empty message is built as : "An Empty message has the Code field set to 0.00. The Token = Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they = MUST be processed as a message format error." If my understanding of the RFC is right, as a CoAP = implementer, do you enforce 0-length token on server side. Is it something you = check in plugtests ? Is it something we want to enforce in an implementation ? Thanks, Matthieu _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Oliver Kleine, M.Sc. UNIVERSIT=C3=84T ZU L=C3=9CBECK INSTITUT F=C3=9CR TELEMATIK Ratzeburger Allee 160 23538 L=C3=BCbeck Tel +49 451 500 5396 Fax +49 451 500 5382 kleine@itm.uni-luebeck.de https://www.itm.uni-luebeck.de/people/kleine _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=20 Oliver Kleine, M.Sc. UNIVERSIT=C3=84T ZU L=C3=9CBECK INSTITUT F=C3=9CR TELEMATIK Ratzeburger Allee 160 23538 L=C3=BCbeck Tel +49 451 500 5396 Fax +49 451 500 5382 kleine@itm.uni-luebeck.de https://www.itm.uni-luebeck.de/people/kleine _______________________________________________ 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 ------=_NextPart_000_0042_01D11AD6.E4C42B80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Robert and Oliver,
 
By RFC7252, the ACK with Empty resopnse of CON should be 4 byte. =
It is a malformed packet if the token length is not ZERO when an = ACK=20 message with Empty response.
  
But, there were arguments to have the Empty response with the token = of=20 request which is in preceeding.
Some implementations accept the empty response with token (the ACK = message=20 sige > 4) is rational,
as it is easy to directly match the request and the response. =
 
If an ACK with ZERO token lenth is received, for matching the = request and=20 response the sender needs to keep the mapping of request token and the = message=20 ID.
After receiving an ACK with ZERO token length, the sender expects = and waits=20 for a separate response of the request token.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Saturday, November 07, 2015 5:40 AM
Subject: Re: [core] ack message format in confirmable=20 notifications
 
I think implementations should really drop messages with = Empty code=20 where the token length is not equal to 0 or the message size is not 4 = bytes.=20 However, I guess it depends what you mean by "accept and proceed" in the = context=20 of dropping messages. As long as the semantic meaning of the Empty code = is=20 processed, then it won't "proceed" much anyway so whether there is any=20 additional token or even payload is probably moot.=20
 
Note the robustness principle is not about handling malformed = packets. It=20 is about handling valid packets formed in a way you wouldn't send = yourself.=20 Malformed (i.e. invalid) packets must be dropped and typically at the = first=20 point of parsing where it is considered malformed.
 
Robert
 
On 6 November 2015 at 18:22, Oliver Kleine = <kleine@itm.uni-luebeck.de> wrote:
Hi=20 Matthieu,

some implementations (maybe most of them) accept and = proceed=20 empty messages with a token length > 0 (and ignore the token, if=20 any).

This is to follow Postels robustness principle (from RFC = 793):=20 "Be conservative in what you do, be liberal in what you accept from = others.",=20 i.e. do not (knowingly) send malformed messages but be prepared to = receive and=20 handle malformed messages from = others.

Best,
Oliver

On=20 06.11.2015 15:01, Matthieu Vial wrote:
Hi=20 Oliver,

Thanks for your answer.
As I understand your = comment, a=20 token length>0 in a notification ack is
malformed but most=20 implementations just don't care. It seems like even
if the RFC = says the=20 length MUST be 0 most implement it as SHOULD be 0.
Is that right=20 ?

BR,
Matthieu

On Fri, Nov 6, 2015 at 2:26 PM, = Oliver=20 Kleine <kleine@itm.uni-luebeck.de
<mailto:kleine@itm.uni-luebeck.de>>=20 wrote:

    Hello = Matthieu,

   =20 according to section 1.2 of RFC 7252 an empty message only=20 contains
    the 4-byte header. The token length = is a part=20 of the header, the
    token itself is not. This = implies a=20 token length of 0 for empty
    messages just = because=20 there is no room left for a token of length >=20 0.

    Thus, empty messages with token length = > 0=20 may be considered
    malformed, as a token length = > 0=20 implies a message larger than 4 byte.

    = Furthermore,=20 on the "semantic" level, there is a difference = between
   =20 a token of length 0 in empty and non-empty messages. In=20 non-empty
    messages the token (incl. the one of = size 0)=20 is basically used to
    relate requests and = responses to=20 each other (see [1] for the plugtests).

    = This does=20 not hold for empty messages. In empty messages, the=20 token
    has no semantic meaning at all. I guess, = that's=20 why there is no
    plugtest to check for token = lengths in=20 empty messages.

    Best=20 regards,
    Oliver

    [1] = http://rawgit.com/cabo/td-coap3/master/base.html = (CORE_10,=20 11, 12)



    On 06.11.2015 09:22, = Matthieu Vial=20 wrote:

        Hi=20 all,

        There is no = example=20 of confirmable notification in RFC7641 and=20 I
       =20 would
        like to clarify = the=20 format of the ack message sent by the=20 coap
       =20 client.

        Basically, = an ack=20 message to a confirmable notification has=20 no
       =20 content
        and no REST = semantics=20 so the code is = 0.00.

       =20 According to https://tools.ietf.org/html/rfc7252#section-3:
&nb= sp;      =20 "As a special case, Code 0.00 indicates an Empty=20 message."

        So this = message=20 should be an empty=20 message.

        According = to https://tools.ietf.org/html/rfc7252#section-4.1=20 an
       =20 empty
        message is built = as=20 :

        "An Empty = message has=20 the Code field set to 0.00.  The Token=20 = Length
          &nb= sp; =20 field MUST be set to 0 and bytes of data MUST NOT=20 be
        present=20 = after
          &nbs= p; =20 the Message ID field.  If there are any bytes, they MUST=20 be
       =20 = processed
          =   =20 as a message format=20 error."

        If my=20 understanding of the RFC is right, as a CoAP=20 implementer,
        do=20 you
        enforce 0-length = token on=20 server side. Is it something you check=20 in
        plugtests ? Is it = something=20 we want to enforce in = an
       =20 implementation ?

       =20 Thanks,
       =20 Matthieu


       =20 = _______________________________________________
   &nbs= p;   =20 core mailing = list
       =20 core@ietf.org = <mailto:core@ietf.org>
    &n= bsp;  =20 https://www.ietf.org/mailman/listinfo/core

   =20 --

    Oliver Kleine,=20 M.Sc.


    UNIVERSIT=C3=84T ZU=20 L=C3=9CBECK
         = INSTITUT F=C3=9CR=20 TELEMATIK

        =20 Ratzeburger Allee = 160
        =20 23538 = L=C3=BCbeck

        = ;=20 Tel +49 451 500 5396=20 = <tel:%2B49%20451%20500%205396>
     &nb= sp;  =20 Fax +49 451 500 5382=20 <tel:%2B49%20451%20500%205382>
    kleine@itm.uni-luebeck.de <mailto:kleine@itm.uni-luebeck.de>

 &nbs= p; =20 https://www.itm.uni-luebeck.de/people/kleine

<= BR>   =20 = _______________________________________________
    = core=20 mailing list
    core@ietf.org <mailto:core@ietf.org>
    https://www.ietf.org/mailman/listinfo/core


--

Oliver Kleine, = M.Sc.


UNIVERSIT=C3=84T ZU=20 L=C3=9CBECK
    INSTITUT F=C3=9CR = TELEMATIK

   =20 Ratzeburger Allee 160
    23538=20 L=C3=BCbeck

    Tel +49 451 500 = 5396
   =20 Fax +49 451 500 5382
    kleine@itm.uni-luebeck.de

    = https://www.itm.uni-luebeck.de/people/kleine

<= /DIV>

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

 

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0042_01D11AD6.E4C42B80-- From nobody Mon Nov 9 01:43:23 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5EC1B7B5F for ; Mon, 9 Nov 2015 01:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JMofxNyjz9E for ; Mon, 9 Nov 2015 01:43:20 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 669E51B7B5C for ; Mon, 9 Nov 2015 01:43:20 -0800 (PST) Received: by igl9 with SMTP id 9so26699137igl.0 for ; Mon, 09 Nov 2015 01:43:19 -0800 (PST) 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:content-type; bh=mUSMElHc5iLT3zqgZ9q6Wsq3qDYUMgHZA7lqaLKlrd8=; b=dTUbCLBLY1FuN6Mzyp+hDTHBWEUnejbLYbaLv0vbZPcHCzLPuzVDJ1vHi8tDP65YkY MbroSSWhJ8AGQf49g7cnc0bitC+9khl+MSp317ykZOcaMrjfp+Z3M50xfDWJ2eJk3rBy aQlgbBAcxAijdd2WVaJW3/kOGAe+WH60flScrMlzERSaKbzX7M1Q+xVfMm+XyM3TWhzW qNqoIvbFRpJubXF22k6ONmoDC5kkI2+eY8AgWnkoazShtT5bDdHdygWsL0lUExZBuA0X TQ/LmC/6ypZ1eVVsWx2HOe5jsinzw0+r7w+yJHVqW5om0hXJlBWYw/3xpkcIDzGNGB58 pfnQ== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr2731700igc.94.1447062199784; Mon, 09 Nov 2015 01:43:19 -0800 (PST) Received: by 10.107.30.20 with HTTP; Mon, 9 Nov 2015 01:43:19 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Nov 2015 10:43:19 +0100 Message-ID: From: Matthieu Vial To: Andrew Mcgregor Content-Type: multipart/alternative; boundary=001a1135e8ca62e36d0524186ce1 Archived-At: Cc: Core Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 09:43:22 -0000 --001a1135e8ca62e36d0524186ce1 Content-Type: text/plain; charset=UTF-8 +1 for adoption. On Tue, Nov 3, 2015 at 5:38 AM, Andrew Mcgregor wrote: > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > --001a1135e8ca62e36d0524186ce1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption.


On Tue, Nov 3, 2015 at 5:38 AM, Andrew= Mcgregor <andrewmcgr@google.com> wrote:
The sense of the room at IETF 94 was th= at we should adopt this as a working group document.

Thi= s is the corresponding mailing list call, open until November 16.

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A TCP and TLS Transport= for the Constrained Application Protocol (CoAP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Aut= hors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Carsten Bormann
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Simon Le= may
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Valik Solorzano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tschofenig= -core-coap-tcp-tls-05.txt=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 12
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-11-02

Abstract:
=C2=A0 =C2=A0The Hypertext Transfer Protocol (= HTTP) was designed with TCP as the
=C2=A0 =C2=A0underlying transport protocol.= =C2=A0 The Constrained Application Protocol
=C2=A0 =C2=A0(CoAP), while inspired = by HTTP, has been defined to make use of UDP
=C2=A0 =C2=A0instead of TCP.=C2=A0 = Therefore, reliable delivery and a simple congestion
=C2=A0 =C2=A0control and fl= ow control mechanism are provided by the message layer
=C2=A0 =C2=A0of the CoAP = protocol.

=C2=A0 =C2=A0A number of environments b= enefit from the use of CoAP directly over a
=C2=A0 =C2=A0reliable byte stream su= ch as TCP, which already provides these
=C2=A0 =C2=A0services.=C2=A0 This docume= nt defines the use of CoAP over TCP as well as
=C2=A0 =C2=A0CoAP over TLS.


The IETF datatracker st= atus page for this draft is:
https://data= tracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05<= /a>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-tschofenig-core-coap-tcp-tls-05

--
Andrew McGregor=C2= =A0|=C2=A0SRE=C2=A0|<= /span>=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 1071 2221

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


--001a1135e8ca62e36d0524186ce1-- From nobody Mon Nov 9 01:53:13 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AEE1B7B87 for ; Mon, 9 Nov 2015 01:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: 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-R_xqEIdoVS for ; Mon, 9 Nov 2015 01:53:10 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00D71B7B89 for ; Mon, 9 Nov 2015 01:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tA99r0DP028635; Mon, 9 Nov 2015 10:53:01 +0100 (CET) Received: from pptp-218-2.informatik.uni-bremen.de (pptp-218-2.informatik.uni-bremen.de [134.102.218.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nvSLM2x0bz2FxM; Mon, 9 Nov 2015 10:52:58 +0100 (CET) Message-ID: <56406CF6.9040302@tzi.org> Date: Mon, 09 Nov 2015 17:52:54 +0800 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: weigengyu References: <563CAA84.7070706@itm.uni-luebeck.de> <563CEFE5.1010101@itm.uni-luebeck.de> <32B1165DE0624F1CB09386E53B67C252@WeiGengyuPC> In-Reply-To: <32B1165DE0624F1CB09386E53B67C252@WeiGengyuPC> 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] ack message format in confirmable notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 09:53:11 -0000 > By RFC7252, the ACK with Empty resopnse of CON should be 4 byte. > It is a malformed packet if the token length is not ZERO when an ACK > message with Empty response. Indeed. > But, there were arguments to have the Empty response with the token of > request which is in preceeding. But that is not how CoAP is defined. So I don't know why this is coming up. > Some implementations accept the empty response with token (the ACK > message sige > 4) is rational, > as it is easy to directly match the request and the response. ACK is on the message layer, and message layer matching is by the message ID. > If an ACK with ZERO token lenth is received, for matching the request > and response the sender needs to keep the mapping of request token and > the message ID. The token length is not the interesting point here. An Empty message has Code 0.00; this distinguishes an Empty ACK from an ACK with a piggybacked response. (A piggybacked response still has token length 0 if the request used a token of zero length.) > After receiving an ACK with ZERO token length, the sender expects and > waits for a separate response of the request token. => After receiving an ACK with code 0.00, the sender expects and waits for a separate response that echoes the request token. Gr眉脽e, Carsten From nobody Mon Nov 9 04:28:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE81B7C22 for ; Mon, 9 Nov 2015 04:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ57Kj4Cs5-x for ; Mon, 9 Nov 2015 04:28:03 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 BAEEE1B7C1D for ; Mon, 9 Nov 2015 04:28:03 -0800 (PST) Received: by igbxm8 with SMTP id xm8so50048332igb.1 for ; Mon, 09 Nov 2015 04:28:03 -0800 (PST) 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:content-type; bh=1QWp84hS1t6OnGb/HRGJZHNss7jlfBjviFXMd6I060w=; b=xX91GQ66WHJoQdwM0pUCzNNKb6TE85qDA040sRFdfUcG3PdtnUPzHIkvfIZ2Vr9ZtQ LfanXmFUdxvIWLWmJu8e6kTAeGe9+wEYIQy/nQGBrHSWQopcEIcG2zGmBsBg5zSDLLZb ho9nyb0fNPPPe5oA05guWtd1z7yifwTi21PraemDexuDTWlPg8QpJvQQLI9CTvDkzJjV B46Q8clnu/LVTYnDOMKhuypSt6tduFh3/arIq+ZMtoyqF07UcH3Ui1SttfH8yDv8faId 0tMp+2NJ/pSDXIvTgGTS5IygPud2X2nwxolGOE1U7r7r8A1nYFZ18tdr/iI5FmO0lWTc 1zVw== MIME-Version: 1.0 X-Received: by 10.50.183.11 with SMTP id ei11mr3232521igc.94.1447072083146; Mon, 09 Nov 2015 04:28:03 -0800 (PST) Received: by 10.107.30.20 with HTTP; Mon, 9 Nov 2015 04:28:03 -0800 (PST) In-Reply-To: <56406CF6.9040302@tzi.org> References: <563CAA84.7070706@itm.uni-luebeck.de> <563CEFE5.1010101@itm.uni-luebeck.de> <32B1165DE0624F1CB09386E53B67C252@WeiGengyuPC> <56406CF6.9040302@tzi.org> Date: Mon, 9 Nov 2015 13:28:03 +0100 Message-ID: From: Matthieu Vial To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a1135e8ca7affef05241ab976 Archived-At: Cc: "core@ietf.org WG" Subject: Re: [core] ack message format in confirmable notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:28:05 -0000 --001a1135e8ca7affef05241ab976 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, I agree for a separate response. But what about an ACK in return to a CON notification ? Some implementations include the observe token in the ACK. Is it considered a valid message ? Thanks, Matthieu On Mon, Nov 9, 2015 at 10:52 AM, Carsten Bormann wrote: > > By RFC7252, the ACK with Empty resopnse of CON should be 4 byte. > > It is a malformed packet if the token length is not ZERO when an ACK > > message with Empty response. > > Indeed. > > > But, there were arguments to have the Empty response with the token of > > request which is in preceeding. > > But that is not how CoAP is defined. So I don't know why this is coming > up. > > > Some implementations accept the empty response with token (the ACK > > message sige > 4) is rational, > > as it is easy to directly match the request and the response. > > ACK is on the message layer, and message layer matching is by the > message ID. > > > If an ACK with ZERO token lenth is received, for matching the request > > and response the sender needs to keep the mapping of request token and > > the message ID. > > The token length is not the interesting point here. > An Empty message has Code 0.00; this distinguishes an Empty ACK from an > ACK with a piggybacked response. (A piggybacked response still has > token length 0 if the request used a token of zero length.) > > > After receiving an ACK with ZERO token length, the sender expects and > > waits for a separate response of the request token. > > =3D> > > After receiving an ACK with code 0.00, the sender expects and > waits for a separate response that echoes the request token. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a1135e8ca7affef05241ab976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carsten,

I agree = for a separate response. But what about an ACK in return to a CON notificat= ion ? Some implementations include the observe token in the ACK. Is it cons= idered a valid message ?

Thanks,
M= atthieu

On Mon, Nov 9, 2015 at 10:52 AM, Carsten Bormann <cabo@tzi.org>= wrote:
> By RFC7252,= the ACK with Empty resopnse of CON should be 4 byte.
> It is a malformed packet if the token length is not ZERO when an ACK > message with Empty response.

Indeed.

> But, there were arguments to have the Empty response with the token of=
> request which is in preceeding.

But that is not how CoAP is defined.=C2=A0 So I don't know why t= his is coming up.

> Some implementations accept the empty response with token (the ACK
> message sige > 4) is rational,
> as it is easy to directly match the request and the response.

ACK is on the message layer, and message layer matching is by the message ID.

> If an ACK with ZERO token lenth is received, for matching the request<= br> > and response the sender needs to keep the mapping of request token and=
> the message ID.

The token length is not the interesting point here.
An Empty message has Code 0.00; this distinguishes an Empty ACK from an
ACK with a piggybacked response.=C2=A0 (A piggybacked response still has token length 0 if the request used a token of zero length.)

> After receiving an ACK with ZERO token length, the sender expects and<= br> > waits for a separate response of the request token.

=3D>

After receiving an ACK with code 0.00, the sender expects and
waits for a separate response that echoes the request token.

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

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

--001a1135e8ca7affef05241ab976-- From nobody Mon Nov 9 04:52:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4D1B2A11 for ; Mon, 9 Nov 2015 04:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB1WDbGxCq8H for ; Mon, 9 Nov 2015 04:52:11 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8845C1B2A0D for ; Mon, 9 Nov 2015 04:52:09 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id BCB1D19F4F3 for ; Mon, 9 Nov 2015 20:52:04 +0800 (HKT) Received: from WeiGengyuPC (unknown [61.51.84.193]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 6BD0219F3EA; Mon, 9 Nov 2015 20:52:04 +0800 (HKT) Message-ID: <68B3ACAEB1CF484CA09DFDA8A58FD6D8@WeiGengyuPC> From: "weigengyu" To: "Matthieu Vial" , "Carsten Bormann" References: <563CAA84.7070706@itm.uni-luebeck.de><563CEFE5.1010101@itm.uni-luebeck.de><32B1165DE0624F1CB09386E53B67C252@WeiGengyuPC><56406CF6.9040302@tzi.org> In-Reply-To: Date: Mon, 9 Nov 2015 20:52:06 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D11B30.7E3FDDF0" 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] ack message format in confirmable notifications X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:52:13 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0040_01D11B30.7E3FDDF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matthieu, It is a malformed message by RFC7252 currently, as I see. And I think that it needs concerning. Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Matthieu Vial=20 Sent: Monday, November 09, 2015 8:28 PM To: Carsten Bormann=20 Cc: weigengyu ; mailto:core@ietf.org=20 Subject: Re: [core] ack message format in confirmable notifications Hi Carsten,=20 I agree for a separate response. But what about an ACK in return to a = CON notification ? Some implementations include the observe token in the = ACK. Is it considered a valid message ? Thanks, Matthieu On Mon, Nov 9, 2015 at 10:52 AM, Carsten Bormann wrote: > By RFC7252, the ACK with Empty resopnse of CON should be 4 byte. > It is a malformed packet if the token length is not ZERO when an ACK > message with Empty response. Indeed. > But, there were arguments to have the Empty response with the token = of > request which is in preceeding. But that is not how CoAP is defined. So I don't know why this is = coming up. > Some implementations accept the empty response with token (the ACK > message sige > 4) is rational, > as it is easy to directly match the request and the response. ACK is on the message layer, and message layer matching is by the message ID. > If an ACK with ZERO token lenth is received, for matching the = request > and response the sender needs to keep the mapping of request token = and > the message ID. The token length is not the interesting point here. An Empty message has Code 0.00; this distinguishes an Empty ACK from = an ACK with a piggybacked response. (A piggybacked response still has token length 0 if the request used a token of zero length.) > After receiving an ACK with ZERO token length, the sender expects = and > waits for a separate response of the request token. =3D> After receiving an ACK with code 0.00, the sender expects and waits for a separate response that echoes the request token. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_0040_01D11B30.7E3FDDF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matthieu,
 
It is a malformed message by RFC7252 currently, as I see.
And I think that it needs concerning.
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Monday, November 09, 2015 8:28 PM
Subject: Re: [core] ack message format in confirmable=20 notifications
 
Hi Carsten,=20
 
I agree for a separate response. But what = about an=20 ACK in return to a CON notification ? Some implementations include the = observe=20 token in the ACK. Is it considered a valid message ?
 
Thanks,
Matthieu
 
On Mon, Nov 9, 2015 at 10:52 AM, Carsten = Bormann <cabo@tzi.org> wrote:
>=20 By RFC7252, the ACK with Empty resopnse of CON should be 4 = byte.
> It is=20 a malformed packet if the token length is not ZERO when an ACK
> = message=20 with Empty response.

Indeed.

> But, = there were=20 arguments to have the Empty response with the token of
> request = which=20 is in preceeding.

But that is not how CoAP is = defined.  So=20 I don't know why this is coming up.

> Some = implementations=20 accept the empty response with token (the ACK
> message sige = > 4) is=20 rational,
> as it is easy to directly match the request and the=20 response.

ACK is on the message layer, and message layer = matching is by the
message ID.

> If an ACK with = ZERO token=20 lenth is received, for matching the request
> and response the = sender=20 needs to keep the mapping of request token and
> the message=20 ID.

The token length is not the interesting point = here.
An=20 Empty message has Code 0.00; this distinguishes an Empty ACK from = an
ACK=20 with a piggybacked response.  (A piggybacked response still = has
token=20 length 0 if the request used a token of zero = length.)

> After=20 receiving an ACK with ZERO token length, the sender expects = and
> waits=20 for a separate response of the request = token.

=3D>

After=20 receiving an ACK with code 0.00, the sender expects and
waits for a = separate response that echoes the request = token.

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

_______________________________________________
core=20 mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
<= /DIV>
 
------=_NextPart_000_0040_01D11B30.7E3FDDF0-- From nobody Mon Nov 9 05:19:16 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CA61B2B0F for ; Mon, 9 Nov 2015 05:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DRUGS_MUSCLE=0.01, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXEtRBGZ9f3d for ; Mon, 9 Nov 2015 05:19:08 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31A1B2B05 for ; Mon, 9 Nov 2015 05:19:07 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id C972919F759 for ; Mon, 9 Nov 2015 21:19:05 +0800 (HKT) Received: from WeiGengyuPC (unknown [61.51.84.193]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5184219F5A5; Mon, 9 Nov 2015 21:19:05 +0800 (HKT) Message-ID: <8C886037FCFB4BBDA0C79FFE7FE51A0B@WeiGengyuPC> From: "weigengyu" To: "Abhijan Bhattacharyya" References: <79A9C92DDABA437888A06EB0D82BA110@WeiGengyuPC>, <8FE79AD6A80C4B8A83BAF485D6B3A489@WeiGengyuPC>, <36F5869FE31AB24485E5E3222C288E1F48FC6766@NABESITE.InterDigital.com> In-Reply-To: Date: Mon, 9 Nov 2015 21:19:07 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011E_01D11B34.44AB9580" 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] New Version Notification for draft-tcs-coap-no-response-option-12.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:19:14 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_011E_01D11B34.44AB9580 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Abhijan=EF=BC=8C=20 Thank you for your explanations. I wish that the draft contexts are clear.=20 Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Abhijan Bhattacharyya=20 Sent: Thursday, November 05, 2015 11:51 PM To: weigengyu=20 Cc: Akbar.Rahman@InterDigital.com ; esko.dijk@philips.com ; cabo@tzi.org = ; core@ietf.org=20 Subject: Re: [core] New Version Notification for = draft-tcs-coap-no-response-option-12.txt Hi Gengyu,=20 You can suppress any type of responses. No distinction. We just wanted = to mention the 'significance' in terms of resource saving. Hope this = clarifies. =20 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 ____________________________________________ -----"weigengyu" wrote: ----- >To: "Abhijan Bhattacharyya" >From: "weigengyu" >Date: 11/05/2015 05:05PM >Cc: , , >, >Subject: Re: [core] New Version Notification for >draft-tcs-coap-no-response-option-12.txt > > > > > >Hi Abhijan, >=20 >In your draft, there is not other contexts about piggybacked and >separate=20 >response.=20 >With these statements, >=E2=80=9CUsing this option with CON type of requests may not have any > significance if piggybacked responses are=20 >triggered. But, in case > the server responds with a separate response=20 >(which, may be, the > client does not care about) then this option=20 >can be useful. > Suppressing the separate response reduces=20 >one additional traffic > in this case. =E2=80=9C , >=20 >the piggybacked response may be sent back and the separate response >may be=20 >suppressed.=20 >Why not to suppress the piggybacked response?=20 >Even though an ACK of CON is needed, the ACK could be with an empty=20 >response instead of a nomormal response. > >And if the piggybacked response is not suppressed, =20 >should the sender expect the suppressed separate response?=20 >=20 >Regards, >=20 >Gengyu=20 >WEI >Network Technology Center >School of Computer=20 >Beijing University of=20 >Posts and Telecommunications > > >=20 > >From: Abhijan Bhattacharyya=20 >Sent: Monday, November 02, 2015 6:28 PM >To: weigengyu=20 >Cc: Akbar.Rahman@InterDigital.com ;=20 >esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org=20 >Subject: Re: [core] New Version Notification for=20 >draft-tcs-coap-no-response-option-12.txt >=20 > >Hi Gengyu, >The description you quoted tries to clarify that No-Response may not >have=20 >any effect in saving network traffic (e.g. for a PUT request) when it >is used in=20 >CON mode and the response is supposed to be piggybacked. Because in >case of=20 >piggybacking you still have the fields for the response code in the >response=20 >message even if you are not sending any response.=20 > >Regards >Abhijan=20 >Bhattacharyya >Associate Consultant >Scientist, Innovation Lab, Kolkata, India >Tata=20 >Consultancy Services >Mailto:=20 >abhijan.bhattacharyya@tcs.com >Website: http://www.tcs.com >____________________________________________ >Experience certainty. IT Services >Business=20 >Solutions >Consulting >____________________________________________ > > >-----"weigengyu" wrote:=20 >----- > >>To: "Rahman, Akbar"=20 >, "Abhijan >>Bhattacharyya"=20 >, >>,=20 >, >>From: "weigengyu"=20 > >>Date: 11/02/2015 09:08AM >>Subject:=20 >Re: [core] New Version Notification=20 >for >>draft-tcs-coap-no-response-option-12.txt >> >> >> >> >> >> >> >> >> >> >> >>Hi=20 >Abhijan, >>=20 >>one question, >>=20 >>> 2. Option=20 >Definition >>> Using this option with CON type of requests may not have=20 >any >> significance if piggybacked responses=20 >are=20 >>triggered. But, in case >> the=20 >server responds with a separate response=20 >>(which, may be,=20 >the >> client does not care about) then this=20 >option=20 >>can be useful. >> Suppressing=20 >the separate response reduces=20 >>one additional=20 >traffic >> in this case. >>=20 >>The=20 >No-reponse option is about request and response layer semantics.=20 >>When=20 >No-response option works, why the piggybacked responses are >>triggered=20 > >>unless No-response is not recognized.=20 >>If the=20 >>No-Response=20 >option works, it would stop the response whether it is >>the=20 > >>piggybacked or the separated.=20 >>It is=20 >>uncleatr why it is=20 >different between the piggybacked and the >>separate. >>=20 >>When=20 >the=20 >>receive ignore the No-Response option, it can response by=20 >piggybacked >>or=20 >>separated way.=20 >>Why does=20 >>the draft=20 >suppose just to suppress the separate response? =20 > >> >>=20 >>And when=20 >>the No-Response works, the ACK of CON=20 >may contain an empty response.=20 >>The=20 >>following process of the=20 >sender side is the same as definitions for >>suppressing=20 >>separate=20 >response. =20 >>=20 >>The CON/ACK=20 >>is about the message layer=20 >semantics.=20 >>It seems=20 >>that the No-reponse does not touch the=20 >message layer semantics.=20 >>=20 >>Regards, >>=20 >>Gengyu=20 > >>WEI >>Network Technology Center >>School of Computer=20 > >>Beijing University of=20 >>Posts and=20 >Telecommunications >> >> >>=20 >> >>From: Rahman, Akbar=20 > >>Sent: Sunday, October 18, 2015 8:17 AM >>To: Abhijan Bhattacharyya=20 >; esko.dijk@philips.com ; cabo@tzi.org ; >>core@ietf.org=20 >>Subject:=20 >Re: [core] New Version Notification for=20 > >>draft-tcs-coap-no-response-option-12.txt >>=20 > >> >> >>>Akbar, The reverse=20 >>proxy consideration have=20 >been included as a new section 4.3. >>=20 >>Thanks,=20 > >>Abhijan. Looks good. >>=20 >>=20 >>=20 >>One=20 > >>other question, why does the draft say =E2=80=9CExpired=E2=80=9D at = the top =20 >even >>though=20 >>the expiry date is April 2016? >>=20 > >>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >>=20 > >>=20 >>=20 >>From: Abhijan=20 >>Bhattacharyya=20 >[mailto:abhijan.bhattacharyya@tcs.com]=20 >>Sent: Thursday,=20 >>October=20 >15, 2015 9:23 AM >>To: esko.dijk@philips.com; cabo@tzi.org;=20 > >>core@ietf.org; Rahman, Akbar=20 > >> >>Subject: Fw: New Version=20 > >>Notification for draft-tcs-coap-no-response-option-12.txt >>=20 > >>Hi Carsten, Esko, Akbar=20 >>and all,=20 >> >>Based on the=20 >recent=20 >>inputs we have shared a new version of the No-Response draft.=20 > >> >> >>Esko, I=20 >>have actually removed the 'Leisure'=20 >stuff for unicast. Thought it was >>making=20 >>things a bit=20 >complicated.=20 >> >>Akbar, The reverse=20 >>proxy consideration have=20 >been included as a new section 4.3.=20 >> >> >>Carsten,=20 > >>requesting your suggestion regarding the next step forward.=20 > >> >>Hoping to see you all=20 >>in Yokohama.=20 > >> >>Regards >>Abhijan=20 >>Bhattacharyya >>Associate=20 >Consultant >>Scientist, Innovation Lab, Kolkata,=20 >>India >>Tata=20 >Consultancy Services >>Mailto:=20 >abhijan.bhattacharyya@tcs.com >>Website:=20 > >>http://www.tcs.com >>____________________________________________ >>Experience=20 > >>certainty. IT=20 > >>Services >> =20 > >>Business=20 > >>Solutions >> =20 > >>Consulting >>____________________________________________ >> >>-----=20 > >>Forwarded by Abhijan Bhattacharyya/KOL/TCS on 10/15/2015 06:45=20 >PM >>-----=20 > >> >> >>From: =20 > >>internet-drafts@ietf.org=20 > >> >>To: =20 >>"Soma=20 > >>Bandyopadhyay" ,=20 >>"Soma=20 >Bandyopadhyay" ,=20 >>"Abhijan=20 >Bhattacharyya" ,=20 >>"Arpan Pal"=20 >,=20 >>"Arpan Pal" ,=20 > >>"Tulika Bose" , "Abhijan=20 > >>Bhattacharyya" ,=20 >>"Tulika=20 >Bose" =20 > >>Date: =20 >>10/15/2015 06:45=20 > >>PM=20 >>Subject: =20 > >>New=20 >>Version Notification for=20 >draft-tcs-coap-no-response-option-12.txt=20 > >> >> >> >> >> >> >> >> >>A new=20 >version of=20 >>I-D, draft-tcs-coap-no-response-option-12.txt >>has been=20 >successfully=20 >>submitted by Tulika Bose and posted to the >>IETF=20 > >>repository. >> >>Name: =20 > >>draft-tcs-coap-no-response-option >>Revision: =20 > >>12 >>Title: =20 > >>CoAP option for no server-response >>Document=20 > >>date: =20 > >>2015-10-15 >>Group: =20 > >>Individual=20 > >>Submission >>Pages: =20 > >>17 >>URL: =20 > >>https://www.ietf.org/internet-drafts/draft-tcs-coap-no-response-opti >o >>n-12.txt >>Status: =20 > >>https://datatracker.ietf.org/doc/draft-tcs-coap-no-response-option/ >>Htmlized: =20 > >>https://tools.ietf.org/html/draft-tcs-coap-no-response-option-12 >>Diff: =20 > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no-response-option- >1 >>2 >> >>Abstract: >> =20 > >>There can be M2M scenarios where responses from server=20 > >>against >> requests from client might be considered=20 >redundant.=20 >>This kind of >> open-loop exchange (with no=20 >response path from=20 >>the server to the >> client) may be=20 >desired to minimize resource=20 >>consumption in >> constrained=20 >systems while simultaneously=20 >>updating a bulk of >> resources=20 >or updating a resource with a=20 >>very high frequency. CoAP >> =20 >already provides a non-confirmable=20 >>(NON) mode of message=20 >exchange >> where the server end-point=20 >>does not respond with=20 >ACK. However, >> obeying the=20 >>request/response semantics, the=20 >server end-point >> responds=20 >>back with a status code=20 >indicating "the result of the >> attempt=20 >>to understand and=20 >satisfy the request". >> >> This draft=20 >>introduces a=20 >header option for CoAP called 'No-Response'. >> =20 >>Using this=20 >option the client explicitly tells the server to=20 >>suppress >> =20 >responses against the particular request. This=20 >>option also=20 >provides >> granular control to enable suppression=20 >>of a=20 >particular class or a >> combination of response-classes.=20 > >>This option may be effective for >> both unicast and=20 >multicast=20 >>requests. Present draft also discusses >> few=20 >exemplary=20 >>applications which benefit from this=20 > >>option. >> >> >> =20 > >> >> >> >>Please note that it may take a couple of minutes=20 >from the=20 >>time of submission >>until the htmlized version and diff=20 >are available=20 >>at tools.ietf.org. >> >>The IETF=20 > >>Secretariat >>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D-----=3D=3D=3D=3D=3D >>Notice: The=20 >information contained in this=20 >>e-mail >>message and/or attachments=20 >to it may contain=20 >>confidential or=20 >>privileged information. If you=20 >are=20 >>not the intended recipient, any=20 >>dissemination, use,=20 > >>review, distribution, printing or copying of the=20 > >> >>information contained in this e-mail message=20 >>and/or=20 >attachments to it=20 >>are strictly prohibited. If=20 >>you have received=20 >this communication in error,=20 >> >>please notify us by reply e-mail or=20 >telephone and=20 >>immediately and=20 >>permanently delete the message=20 > >>and any attachments. Thank=20 > >>you >> >> >>_______________________________________________ >>core=20 >mailing=20 > >>list >>core@ietf.org >>https://www.ietf.org/mailman/listinfo/core >> >> > ------=_NextPart_000_011E_01D11B34.44AB9580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Abhijan=EF=BC=8C =
 
Thank you for your explanations.
I wish that the draft contexts are clear. =
 
Regards, 
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Abhijan Bhattacharyya =
Sent: Thursday, November 05, 2015 11:51 PM
Cc: Akbar.Rahman@InterDigital.c= om ;=20 esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org =
Subject: Re: [core] New Version Notification for=20 draft-tcs-coap-no-response-option-12.txt
 
Hi Gengyu,=20
You can suppress any type of responses. No distinction. = We just=20 wanted to mention the 'significance' in terms of resource saving. Hope = this=20 clarifies. 

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

-----"weigengyu" <weigengyu@bupt.edu.cn> wrote:=20 -----

>To: "Abhijan Bhattacharyya"=20 <abhijan.bhattacharyya@tcs.com>
>From: "weigengyu"=20 <weigengyu@bupt.edu.cn>
>Date: 11/05/2015 05:05PM
>Cc: = <Akbar.Rahman@InterDigital.com>,=20 <esko.dijk@philips.com>,
><cabo@tzi.org>,=20 <core@ietf.org>
>Subject: Re: [core] New Version = Notification=20 for
>draft-tcs-coap-no-response-option-12.txt
>
>
&g= t;
>
>
>Hi=20 Abhijan,
>
>In your draft, there is not other contexts = about=20 piggybacked and
>separate
>response.
>With these=20 statements,
>=E2=80=9CUsing this option with CON type of requests = may not have=20 any
>      significance if piggybacked = responses=20 are
>triggered. But, in = case
>      the=20 server responds with a separate response
>(which, may be,=20 the
>      client does not care about) = then this=20 option
>can be useful.
>      = Suppressing=20 the separate response reduces
>one additional=20 traffic
>      in this case. =E2=80=9C = ,
>=20
>the piggybacked response may be sent back and the separate=20 response
>may be
>suppressed.
>Why not to suppress = the=20 piggybacked response?
>Even though an ACK of CON is needed, the = ACK could=20 be with an empty
>response instead of a nomormal=20 response.
>
>And if the piggybacked response is not=20 suppressed, 
>should the sender expect the suppressed = separate=20 response?
>
>Regards,
>
>Gengyu=20
>WEI
>Network Technology Center
>School of Computer=20
>Beijing University of
>Posts and=20 Telecommunications
>
>
>
>
>From: Abhijan = Bhattacharyya
>Sent: Monday, November 02, 2015 6:28 PM
>To: = weigengyu
>Cc: Akbar.Rahman@InterDigital.com ;=20
>esko.dijk@philips.com ; cabo@tzi.org ; core@ietf.org =
>Subject:=20 Re: [core] New Version Notification for=20
>draft-tcs-coap-no-response-option-12.txt
> =
>
>Hi=20 Gengyu,
>The description you quoted tries to clarify that = No-Response may=20 not
>have
>any effect in saving network traffic (e.g. for a = PUT=20 request) when it
>is used in
>CON mode and the response is = supposed=20 to be piggybacked. Because in
>case of
>piggybacking you = still have=20 the fields for the response code in the
>response
>message = even if=20 you are not sending any response.
>
>Regards
>Abhijan =
>Bhattacharyya
>Associate Consultant
>Scientist, = Innovation=20 Lab, Kolkata, India
>Tata
>Consultancy = Services
>Mailto:=20
>abhijan.bhattacharyya@tcs.com
>Website:=20 http://www.tcs.com
>____________________________________________>Experience=20 certainty. IT Services
>Business=20
>Solutions
>Consulting
>______________________________= ______________
>
>
>-----"weigengyu"=20 <weigengyu@bupt.edu.cn> wrote: =
>-----
>
>>To:=20 "Rahman, Akbar"
><Akbar.Rahman@InterDigital.com>,=20 "Abhijan
>>Bhattacharyya"=20
><abhijan.bhattacharyya@tcs.com>,
>><esko.dijk@p= hilips.com>,=20
><cabo@tzi.org>, <core@ietf.org>
>>From: = "weigengyu"=20
><weigengyu@bupt.edu.cn>
>>Date: 11/02/2015=20 09:08AM
>>Subject:
>Re: [core] New Version Notification=20
>for
>>draft-tcs-coap-no-response-option-12.txt
>&g= t;
>>
>>
>>
>>
>>
>>= ;<!--
>>/*=20
>Font Definitions */
>>@font-face
>>=20 {font-family:"Cambria
>Math";
>> panose-1:2 4 5 3 5 4 6 = 3 2=20 4;}
>>@font-face
>> =
>{font-family:Calibri;
>>=20 panose-1:2 15 5 2 2 2 4 3 2 4;}
>>/* Style
>Definitions=20 */
>>p.MsoNormal, li.MsoNormal, div.MsoNormal
>>=20
>{margin:0in;
>> margin-bottom:.0001pt;
>>=20 font-size:12.0pt;
>>
>font-family:"Times New=20 Roman",serif;}
>>a:link, span.MsoHyperlink
>>=20
>{mso-style-priority:99;
>> color:blue;
>>=20
>text-decoration:underline;}
>>a:visited,=20 span.MsoHyperlinkFollowed
>>=20
>{mso-style-priority:99;
>> color:purple;
>>=20
>text-decoration:underline;}
>>p
>>=20 {mso-style-priority:99;
>> =
>mso-margin-top-alt:auto;
>>=20 margin-right:0in;
>> =
>mso-margin-bottom-alt:auto;
>>=20 margin-left:0in;
>>
>font-size:12.0pt;
>>=20 font-family:"Times New
>Roman",serif;}
>>tt
>>=20 {mso-style-priority:99;
>>
>font-family:"Courier=20 New";}
>>span.EmailStyle19
>>=20
>{mso-style-type:personal-reply;
>>=20
>font-family:"Calibri",sans-serif;
>>=20
>color:#1F497D;}
>>.MsoChpDefault
>>=20
>{mso-style-type:export-only;
>>=20
>font-family:"Calibri",sans-serif;}
>>@page=20 WordSection1
>> {size:8.5in
>11.0in;
>> = margin:1.0in=20 1.0in 1.0in 1.0in;}
>>div.WordSection1
>>=20
>{page:WordSection1;}
>>-->
>>
>>>>
>>
>>Hi=20
>Abhijan,
>>
>>one question,
>>=20
>>> 2. Option
>Definition
>>> Using this = option=20 with CON type of requests may not have=20
>any
>>      significance if=20 piggybacked responses
>are
>>triggered. But, in=20 case
>>      the
>server = responds with=20 a separate response
>>(which, may be,=20
>the
>>      client does not = care=20 about) then this
>option
>>can be=20 useful.
>>      Suppressing =
>the=20 separate response reduces
>>one additional=20
>traffic
>>      in this=20 case.
>>
>>The
>No-reponse option is about = request and=20 response layer semantics.
>>When
>No-response option = works, why=20 the piggybacked responses are
>>triggered =
>
>>unless=20 No-response is not recognized.
>>If the =
>>No-Response=20
>option works, it would stop the response whether it = is
>>the=20
>
>>piggybacked or the separated.
>>It is=20
>>uncleatr why it is
>different between the piggybacked = and=20 the
>>separate.
>>
>>When
>the=20
>>receive ignore the No-Response option, it can response by=20
>piggybacked
>>or
>>separated way. =
>>Why=20 does
>>the draft
>suppose just to suppress the separate = response?   
>
>>
>> =
>>And=20 when
>>the No-Response works, the ACK of CON
>may = contain an=20 empty response.
>>The
>>following process of the=20
>sender side is the same as definitions = for
>>suppressing=20
>>separate
>response. 
>> =
>>The=20 CON/ACK
>>is about the message layer
>semantics. =
>>It=20 seems
>>that the No-reponse does not touch the
>message = layer=20 semantics.
>>
>>Regards,
>> =
>>Gengyu=20
>
>>WEI
>>Network Technology = Center
>>School=20 of Computer
>
>>Beijing University of
>>Posts = and=20
>Telecommunications
>>
>>
>>=20
>>
>>From: Rahman, Akbar
>
>>Sent: = Sunday,=20 October 18, 2015 8:17 AM
>>To: Abhijan Bhattacharyya
>;=20 esko.dijk@philips.com ; cabo@tzi.org ;
>>core@ietf.org=20
>>Subject:
>Re: [core] New Version Notification for=20
>
>>draft-tcs-coap-no-response-option-12.txt
>> =
>
>>
>>
>>>Akbar, The reverse=20
>>proxy consideration have
>been included as a new = section=20 4.3.
>>
>>Thanks,
>
>>Abhijan.  = Looks=20 good.
>>
>>
>>
>>One=20
>
>>other question, why does the draft say = =E2=80=9CExpired=E2=80=9D at the=20 top 
>even
>>though
>>the expiry date is = April=20 2016?
>>=20
>
>>https://tools.ietf.org/html/draft-tcs-coap-no-respons= e-option-12
>>=20
>
>>
>>
>>From: Abhijan=20
>>Bhattacharyya
>[mailto:abhijan.bhattacharyya@tcs.com] =
>>Sent: Thursday,
>>October
>15, 2015 9:23=20 AM
>>To: esko.dijk@philips.com; cabo@tzi.org;=20
>
>>core@ietf.org; Rahman, Akbar=20
>
>><Akbar.Rahman@InterDigital.com>
>>Subj= ect:=20 Fw: New Version
>
>>Notification for=20 draft-tcs-coap-no-response-option-12.txt
>> =
>
>>Hi=20 Carsten, Esko, Akbar
>>and all,
>>
>>Based = on the=20
>recent
>>inputs we have shared a new version of the=20 No-Response draft.
>
>>
>>
>>Esko, I=20
>>have actually removed the 'Leisure'
>stuff for = unicast.=20 Thought it was
>>making
>>things a bit =
>complicated.=20
>>
>>Akbar, The reverse
>>proxy = consideration have=20
>been included as a new section 4.3.=20
>>
>>
>>Carsten, =
>
>>requesting your=20 suggestion regarding the next step forward.=20
>
>>
>>Hoping to see you all
>>in = Yokohama.=20
>
>>
>>Regards
>>Abhijan=20
>>Bhattacharyya
>>Associate=20
>Consultant
>>Scientist, Innovation Lab, Kolkata,=20
>>India
>>Tata
>Consultancy=20 Services
>>Mailto:=20
>abhijan.bhattacharyya@tcs.com
>>Website:=20
>
>>http://www.tcs.com
>>_______________________= _____________________
>>Experience=20
>
>>certainty.        = IT=20
>
>>Services
>>     &nb= sp;           &nbs= p;    =20
>
>>Business=20
>
>>Solutions
>>     &n= bsp;           &nb= sp;    =20
>
>>Consulting
>>_______________________________= _____________
>>
>>-----=20
>
>>Forwarded by Abhijan Bhattacharyya/KOL/TCS on = 10/15/2015=20 06:45
>PM
>>-----=20
>
>>
>>
>>From:    =    =20
>
>>internet-drafts@ietf.org=20
>
>>
>>To:      &n= bsp;=20
>>"Soma
>
>>Bandyopadhyay"=20 <soma.bandyopadhyay@tcs.com>,
>>"Soma =
>Bandyopadhyay"=20 <soma.bandyopadhyay@tcs.com>,
>>"Abhijan =
>Bhattacharyya"=20 <abhijan.bhattacharyya@tcs.com>,
>>"Arpan Pal"=20
><arpan.pal@tcs.com>,
>>"Arpan Pal"=20 <arpan.pal@tcs.com>,
>
>>"Tulika Bose"=20 <tulika.bose@tcs.com>, "Abhijan
>
>>Bhattacharyya" = <abhijan.bhattacharyya@tcs.com>,
>>"Tulika
>Bose" = <tulika.bose@tcs.com>=20
>
>>Date:       =20
>>10/15/2015 06:45
>
>>PM=20
>>Subject:       =20
>
>>New
>>Version Notification for=20
>draft-tcs-coap-no-response-option-12.txt=20
>
>>
>>
>>
>>
>>
&= gt;>
>>
>>
>>A=20 new
>version of
>>I-D,=20 draft-tcs-coap-no-response-option-12.txt
>>has been=20
>successfully
>>submitted by Tulika Bose and posted to=20 the
>>IETF=20
>
>>repository.
>>
>>Name:  &= nbsp;           &n= bsp;           &nb= sp;      =20
>
>>draft-tcs-coap-no-response-option
>>Revision= :            =     =20
>
>>12
>>Title:     &nb= sp;           &nbs= p;            = ;   =20
>
>>CoAP option for no = server-response
>>Document=20
>
>>date:        =         =20
>
>>2015-10-15
>>Group:    &= nbsp;           &n= bsp;           &nb= sp;    =20
>
>>Individual=20
>
>>Submission
>>Pages:    &= nbsp;           &n= bsp;           &nb= sp;    =20
>
>>17
>>URL:      = ;     =20
>
>>https://www.ietf.org/internet-drafts/draft-tcs-coap-n= o-response-opti
>o
>>n-12.txt
>>Status: &nbs= p;      =20
>
>>https://datatracker.ietf.org/doc/draft-tcs-coap-no-re= sponse-option/
>>Htmlized:      =20
>
>>https://tools.ietf.org/html/draft-tcs-coap-no-respons= e-option-12
>>Diff:       &nb= sp;  =20
>
>>https://www.ietf.org/rfcdiff?url2=3Ddraft-tcs-coap-no= -response-option-
>1
>>2
>>
>>Abstract:<= BR>>> =20
>
>>There can be M2M scenarios where responses from = server=20
>
>>against
>>  requests from client might = be=20 considered
>redundant.
>>This kind of
>>  = open-loop exchange (with no
>response path from
>>the = server to=20 the
>>  client) may be
>desired to minimize = resource=20
>>consumption in
>>  constrained
>systems = while=20 simultaneously
>>updating a bulk of
>>  = resources=20
>or updating a resource with a
>>very high frequency.=20 CoAP
>> 
>already provides a non-confirmable=20
>>(NON) mode of message
>exchange
>>  = where the=20 server end-point
>>does not respond with
>ACK.=20 However,
>>  obeying the
>>request/response = semantics,=20 the
>server end-point
>>  responds
>>back = with a=20 status code
>indicating "the result of the
>>  = attempt=20
>>to understand and
>satisfy the=20 request".
>>
>>  This draft =
>>introduces a=20
>header option for CoAP called 'No-Response'.
>> =20
>>Using this
>option the client explicitly tells the = server to=20
>>suppress
>> 
>responses against the = particular=20 request. This
>>option also
>provides
>>  = granular control to enable suppression
>>of a =
>particular class=20 or a
>>  combination of response-classes. =
>
>>This=20 option may be effective for
>>  both unicast and =
>multicast=20
>>requests. Present draft also discusses
>>  few =
>exemplary
>>applications which benefit from this=20
>
>>option.
>>
>>
>> &nbs= p;         =20
>
>>
>>
>>
>>Please note that = it may=20 take a couple of minutes
>from the
>>time of=20 submission
>>until the htmlized version and diff
>are = available=20
>>at tools.ietf.org.
>>
>>The IETF=20
>
>>Secretariat
>>=3D=3D=3D=3D=3D-----=3D=3D=3D=3D= =3D-----=3D=3D=3D=3D=3D
>>Notice:=20 The
>information contained in this =
>>e-mail
>>message=20 and/or attachments
>to it may contain
>>confidential or =
>>privileged information. If you
>are
>>not = the=20 intended recipient, any
>>dissemination, use,=20
>
>>review, distribution, printing or copying of the=20
>
>>
>>information contained in this e-mail = message=20
>>and/or
>attachments to it
>>are strictly=20 prohibited. If
>>you have received
>this communication = in=20 error,
>>
>>please notify us by reply e-mail or=20
>telephone and
>>immediately and =
>>permanently delete=20 the message
>
>>and any attachments. Thank=20
>
>>you
>>
>>
>>______________= _________________________________
>>core=20
>mailing=20
>
>>list
>>core@ietf.org
>>https://www.= ietf.org/mailman/listinfo/core
>>
>>
>
------=_NextPart_000_011E_01D11B34.44AB9580-- From nobody Mon Nov 9 05:34:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3503C1B2BAA for ; Mon, 9 Nov 2015 05:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGfNWfACrdeo for ; Mon, 9 Nov 2015 05:34:18 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id A8D771B2BA8 for ; Mon, 9 Nov 2015 05:34:16 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 267DF19F59C for ; Mon, 9 Nov 2015 21:34:15 +0800 (HKT) Received: from WeiGengyuPC (unknown [61.51.84.193]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id DB51C19F3EC for ; Mon, 9 Nov 2015 21:34:14 +0800 (HKT) Message-ID: <1A4BDE47622E4F98B4D1F378B4FDAC5A@WeiGengyuPC> From: "weigengyu" To: "Core" References: In-Reply-To: Date: Mon, 9 Nov 2015 21:34:16 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01D11B36.62CD2310" 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: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 13:34:21 -0000 这是一封 MIME 格式的多方邮件。 ------=_NextPart_000_0137_01D11B36.62CD2310 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, +1. It is important.=20 And one question.=20 Does it need to give more specifications about the UDP-to-TCP and = TCP-to-UDP gateways?=20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Julien Vermillard=20 Sent: Sunday, November 08, 2015 3:14 PM To: Core=20 Subject: Re: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls +1 =20 We suffer the same issues between our servers and our cellular modems. On some network we need to go down to 20 seconds. Julien Le sam. 7 nov. 2015 22:17, Juan Perez a = =C3=A9crit : +1 It is important for us (at Microsoft Azure IoT) that this document = gets adopted. Additionally, as part of the OMA LWM2M group, = it=E2=80=99s important that CoAP supports TCP/TLS as a standard to = enable internet/cloud scenarios. =20 We=E2=80=99ve run tests between worldwide Azure and non-Azure data = centers and have found that a UDP keep-alive is required no more than = every 30 seconds in order to maintain reachability between clients and = servers. =20 Thanks, Juan From: Andrew Mcgregor [mailto:andrewmcgr@google.com]=20 Sent: Monday, November 2, 2015 8:38 PM To: Core Subject: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls The sense of the room at IETF 94 was that we should adopt this as a = working group document. This is the corresponding mailing list call, open until November 16. Title : A TCP and TLS Transport for the Constrained = Application Protocol (CoAP) Authors : Carsten Bormann Simon Lemay Valik Solorzano Barboza Hannes Tschofenig Filename : draft-tschofenig-core-coap-tcp-tls-05.txt Pages : 12 Date : 2015-11-02 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-tschofenig-core-coap-tcp-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 A diff from the previous version is available at: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-05= --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 _______________________________________________ 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 ------=_NextPart_000_0137_01D11B36.62CD2310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
 
+1.  It is important.
 
And one question.
Does it need to give more specifications about the UDP-to-TCP and=20 TCP-to-UDP gateways?
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
Sent: Sunday, November 08, 2015 3:14 PM
To: Core=20
Subject: Re: [core] Call for adoption of=20 draft-tschofenig-core-coap-tcp-tls
 

+1 

We suffer the same issues between our servers and our = cellular=20 modems.
On some network we need to go down to 20 seconds.

Julien


Le sam. 7 nov. 2015 22:17, Juan Perez <juanpere@microsoft.com> a = =C3=A9crit=20 :

+1

 

It=20 is important for us (at Microsoft Azure IoT) that this document gets=20 adopted.  Additionally, as part of the OMA LWM2M group, = it=E2=80=99s important=20 that CoAP supports TCP/TLS as a standard to enable internet/cloud=20 scenarios. 

 

We=E2=80=99ve=20 run tests between worldwide Azure and non-Azure data centers and have = found=20 that a UDP keep-alive is required no more than every 30 seconds in = order to=20 maintain reachability between clients and servers. =20

 

Thanks,

Juan

 

From: Andrew = Mcgregor=20 [mailto:andrewmcgr@google.com]
Sent: Monday, = November 2,=20 2015 8:38 PM
To: Core <core@ietf.org>
Subject: [core] Call = for=20 adoption of=20 = draft-tschofenig-core-coap-tcp-tls

 

The sense of the room at IETF 94 was that we = should adopt=20 this as a working group document.

 

This is the corresponding mailing list call, open = until=20 November 16.

 

       =20 Title           : A = TCP and=20 TLS Transport for the Constrained Application Protocol=20 (CoAP)
       =20 Authors         : Carsten=20 = Bormann
          &n= bsp;           &nb= sp;  =20 Simon=20 = Lemay
          &nbs= p;            = ;  =20 Valik Solorzano=20 = Barboza
          &n= bsp;           &nb= sp;  =20 Hannes Tschofenig
       =20 Filename        :=20 = draft-tschofenig-core-coap-tcp-tls-05.txt
    &nbs= p;  =20 Pages           :=20 12
       =20 Date            = :=20 2015-11-02

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

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


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

There's also a htmlized version = available=20 at:
https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05<= /SPAN>

A diff from the previous version is = available=20 at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp= -tls-05

 

--

Andrew=20 McGregor |=20 SRE | andrewmcgr@google.com=20 |=20 +61 4 1071=20 = 2221

________= _______________________________________
core=20 mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing=20 list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
------=_NextPart_000_0137_01D11B36.62CD2310-- From nobody Tue Nov 10 08:59:28 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080D61B3ABB for ; Tue, 10 Nov 2015 08:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg1nWyq2yrUz for ; Tue, 10 Nov 2015 08:59:23 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 5CDA91B3AB6 for ; Tue, 10 Nov 2015 08:59:23 -0800 (PST) Received: by oige206 with SMTP id e206so1597826oig.2 for ; Tue, 10 Nov 2015 08:59:22 -0800 (PST) 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 :content-type; bh=+I5QvW3LiKi6x0bwbLBI58G/iPK9ICBnVTqpCZTjTP0=; b=b4ObZ5X8QIxcbrt4CLKBWsfheNkTUinmmn16EilwNQt2IJjgBG8vaa8YtgUqyy//h9 WPNiugkOVSeWElcOXvrHcSqmCw2bgUvL19+b9FaChtMK5KeeCQhhrp4Ip2AJdssu/+gr /Fzn222YpB3BrvOvTN6U70U3Bni2TnBsmatJt36T0MUDR5eDozXCtHaOk+FMpBB4ZqJ9 x4b/hqlKuZsCP3HJT+u1urw0D18AsSOpMcVSs+24n+qXI3euwsV8RWlsRc3eJ729wu9b oqnD+dbjKRdLMywYiBgHzyAr2Yy0QKE11f0IH2RSomzkkWPCRTf8a1QKtNe9k8RIAA2Q Zvcg== X-Received: by 10.202.184.130 with SMTP id i124mr1925502oif.122.1447174762590; Tue, 10 Nov 2015 08:59:22 -0800 (PST) MIME-Version: 1.0 References: <1A4BDE47622E4F98B4D1F378B4FDAC5A@WeiGengyuPC> In-Reply-To: <1A4BDE47622E4F98B4D1F378B4FDAC5A@WeiGengyuPC> From: Simon Lemay Date: Tue, 10 Nov 2015 16:59:12 +0000 Message-ID: To: weigengyu , Core Content-Type: multipart/alternative; boundary=001a113ce0f2a6f92f052432a17f Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 16:59:27 -0000 --001a113ce0f2a6f92f052432a17f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for adoption On Mon, Nov 9, 2015 at 05:34 weigengyu wrote: > Hi all, > > +1. It is important. > > And one question. > Does it need to give more specifications about the UDP-to-TCP and > TCP-to-UDP gateways? > > Regards, > > Gengyu WEI > Network Technology Center > School of Computer > Beijing University of Posts and Telecommunications > > *From:* Julien Vermillard > *Sent:* Sunday, November 08, 2015 3:14 PM > *To:* Core > *Subject:* Re: [core] Call for adoption of > draft-tschofenig-core-coap-tcp-tls > > > +1 > > We suffer the same issues between our servers and our cellular modems. > On some network we need to go down to 20 seconds. > > Julien > > Le sam. 7 nov. 2015 22:17, Juan Perez a =C3=A9cr= it : > >> +1 >> >> >> >> It is important for us (at Microsoft Azure IoT) that this document gets >> adopted. Additionally, as part of the OMA LWM2M group, it=E2=80=99s imp= ortant that >> CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios. >> >> >> >> We=E2=80=99ve run tests between worldwide Azure and non-Azure data cente= rs and >> have found that a UDP keep-alive is required no more than every 30 secon= ds >> in order to maintain reachability between clients and servers. >> >> >> >> Thanks, >> >> Juan >> >> >> >> *From:* Andrew Mcgregor [mailto:andrewmcgr@google.com] >> *Sent:* Monday, November 2, 2015 8:38 PM >> *To:* Core >> *Subject:* [core] Call for adoption of draft-tschofenig-core-coap-tcp-tl= s >> >> >> >> The sense of the room at IETF 94 was that we should adopt this as a >> working group document. >> >> >> >> This is the corresponding mailing list call, open until November 16. >> >> >> >> Title : A TCP and TLS Transport for the Constrained >> Application Protocol (CoAP) >> Authors : Carsten Bormann >> Simon Lemay >> Valik Solorzano Barboza >> Hannes Tschofenig >> Filename : draft-tschofenig-core-coap-tcp-tls-05.txt >> Pages : 12 >> Date : 2015-11-02 >> >> 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-tschofenig-core-coap-tcp-tls/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-0= 5 >> >> >> >> -- >> >> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >> > ------------------------------ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a113ce0f2a6f92f052432a17f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for adoption
On Mon, Nov= 9, 2015 at 05:34 weigengyu <we= igengyu@bupt.edu.cn> wrote:
Hi all,
=C2=A0
+1.=C2=A0 It is important.
=C2=A0
And one question.
Does it need to give more specifications about the UDP-to-TCP and=20 TCP-to-UDP gateways?
=C2=A0
Regards,
=C2=A0
G= engyu=20 WEI
Network Technology Center
School of Computer
Beijing Universi= ty of=20 Posts and Telecommunications
=C2=A0
Sent: Sunday, November 08, 2015 3:14 PM
To: Core=20
Subject: Re: [core] Call for adoption of=20 draft-tschofenig-core-coap-tcp-tls
=C2=A0
=

+1=C2=A0

We suffer the same issues between our servers and our cellul= ar=20 modems.
On some network we need to go down to 20 seconds.

Julien


Le sam. 7 nov. 2015 22:17, Juan Perez <juanpere@microsoft.com> = a =C3=A9crit=20 :

+1

=C2=A0

It=20 is important for us (at Microsoft Azure IoT) that this document gets=20 adopted.=C2=A0 Additionally, as part of the OMA LWM2M group, it=E2=80=99s= important=20 that CoAP supports TCP/TLS as a standard to enable internet/cloud=20 scenarios.=C2=A0

=C2=A0

We=E2=80=99ve=20 run tests between worldwide Azure and non-Azure data centers and have fou= nd=20 that a UDP keep-alive is required no more than every 30 seconds in order = to=20 maintain reachability between clients and servers.=C2=A0=20

=C2=A0

Thanks,

Juan

=C2=A0<= /p>

From: Andrew Mcgregor=20 [mailto:andrew= mcgr@google.com]
Sent: Monday, November 2,=20 2015 8:38 PM
To: Core <core@ietf.org>
Subject: [core] Call for=20 adoption of=20 draft-tschofenig-core-coap-tcp-tls

=C2=A0

The sense of the room at IETF 94 was that we shoul= d adopt=20 this as a working group document.

=C2=A0

This is the corresponding mailing list call, open = until=20 November 16.

=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=20 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : A TCP= and=20 TLS Transport for the Constrained Application Protocol=20 (CoAP)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Carsten=20 Bormann
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=20 Simon=20 Lemay
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=20 Valik Solorzano=20 Barboza
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=20 Hannes Tschofenig
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :=20 draft-tschofenig-core-coap-tcp-tls-05.txt
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=20 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 :=20 12
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 := =20 2015-11-02

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

=C2=A0=C2= =A0 A=20 number of environments benefit from the use of CoAP directly over=20 a
=C2=A0=C2=A0 reliable byte stream such as TCP, which already provide= s=20 these
=C2=A0=C2=A0 services.=C2=A0 This document defines the use of Co= AP=20 over TCP as well as
=C2=A0=C2=A0 CoAP over TLS.


The IETF=20 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= tschofenig-core-coap-tcp-tls/
There's also a htmlized version available=20 at:
https:= //tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05

A diff from the previous version is avai= lable=20 at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-05=

=C2=A0

--

Andr= ew=20 McGregor |=20 SRE |=C2=A0andrewmcgr@google.com=20 |=20 +61 4 1071=20 2221

________= _______________________________________
core=20 mailing list
core@i= etf.org
https://www.ietf.org/mailman/listinfo/cor= e

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

=
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--001a113ce0f2a6f92f052432a17f-- From nobody Thu Nov 12 10:31:17 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC491B2D65; Thu, 12 Nov 2015 10:30:50 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKNhgYgXgzbh; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19871B2BF3; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B868D880E4; Thu, 12 Nov 2015 10:30:47 -0800 (PST) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DD167328081A; Thu, 12 Nov 2015 10:30:44 -0800 (PST) References: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> To: "6lo@ietf.org" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "ipv6@ietf.org" , ace@ietf.org, core@ietf.org, lwip@ietf.org, "int-area@ietf.org" From: Brian Haberman X-Forwarded-Message-Id: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> Message-ID: <5644DAD3.30904@innovationslab.net> Date: Thu, 12 Nov 2015 13:30:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110200512.31690.50934.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps" Archived-At: Subject: [core] Fwd: New Non-WG Mailing List: lp-wan -- Low-Power Wide Area Networking (LP-WAN), also known as LPWA or Low-Rate WAN (LR-WAN) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:30:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, This new mailing list may be of interest. It is hosting discussion on deploying IP on very constrained wireless systems. Regards, Brian -------- Forwarded Message -------- Subject: New Non-WG Mailing List: lp-wan -- Low-Power Wide Area Networking (LP-WAN), also known as LPWA or Low-Rate WAN (LR-WAN) Date: Tue, 10 Nov 2015 12:05:12 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List A new IETF non-working group email list has been created. List address: lp-wan@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dlp-wan To subscribe: https://www.ietf.org/mailman/listinfo/lp-wan Purpose: An LP-WAN has unique constraints, not seen until now - operation in the ISM bands (unlicensed spectrum), very low throughput (300 bps - 50 kbps), very high density (10 000-100 000 nodes per Access Point (AP)), infrastructure networks (star topology, no need for routing), AP diversity (several APs can receive the same signal), coexistence of public networks (country-wide) and private networks (city, building, campus). Asymmetric links are also common, with at least one major technology providing exclusively unidirectional data services. LP-WANs will form the backbone of major IoT applications related to many domains, such as Smart City, Smart Metering, ITS and are expected to connect 3 billion devices by 2020. There are several such LP- WAN radio technologies (Semtech LoRa, SigFox, Qowisio, others), each having a proprietary, locked-in, non-standard solution for addressing, localization, security, provisioning, AAA, etc. This is the case because the stringent LP-WAN constraints do not allow for classical approaches to be used as-is. The goal of this mailing list is to discuss the problems that arise in LP-WANs and how the IETF-based solutions apply to them. This is the place to identify the candidate LP-WAN technologies, their specific constraints and limitations, consider the corresponding IETF approaches, and discuss the need for profiles or adaptations of the existing solution= s. For additional information, please contact the list administrators. --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWRNrTAAoJEBOZRqCi7goqpCMH/AxkhQOfVmCb3kFawBqNTAOb /sbMFYyh3glVxOsQersJAbvaXIFrx4qnJAj7nh35NmVm4d1YQO5zuocJRfUg6NSk 74+sZAGKYaheJz3QDhf6sd8bceS7gNlkhFvgT327SKslSVEqCWyCHSFRBtdMhchk oPrfuAmrmmk/TTEFHLYVoBX+eViEnGxCwMu+Jq/bQLTc9XFPRn7WQ7LRN/p/rbHR u7MODoBAYxRZ2ItnYuMaaUFp421G65HZkkRra63kCw6BXE9sc6vtvwlmsuOFzGcl o94gi6ZbTTYJj3CKoAu43eZxiTzq9eXeBCiAyELIO6vcbpIy7/+rMZ5s5uDeCo8= =ETmP -----END PGP SIGNATURE----- --trg4vLsdRRleRJ6mNX2lSlQg4MIMxuxps-- From nobody Sun Nov 15 17:11:28 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9611AD0D1 for ; Sun, 15 Nov 2015 17:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_vuLtQfWIrn for ; Sun, 15 Nov 2015 17:11:24 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.18]) by ietfa.amsl.com (Postfix) with ESMTP id 930C91AD0CC for ; Sun, 15 Nov 2015 17:11:24 -0800 (PST) Received: from userPC (unknown [122.166.172.226]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id E60CC782779; Mon, 16 Nov 2015 01:11:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1447636291; bh=yA9q/J5tm8X3Lx2AxbC4KCSMKTTHF02iJhv8WgBRKxY=; h=From:To:References:In-Reply-To:Subject:Date; b=mZJzofFQfLNHRW5diWnG310QOAqAaVYMUZbMitAnuscsD+C3i2z8NzjuRPzimssP8 42aYvLzkzaGwxW+oslpCv2/MxL7zyG2uSY4r8YiSTbVFc8A7r9u0lgGTu4b479n4Xm z9NsW6NuJk24A6lcLArpipfTmMgWDcQ3mrsE70xI= From: "Parthasarathi R" To: "'Simon Lemay'" , "'weigengyu'" , "'Core'" References: <1A4BDE47622E4F98B4D1F378B4FDAC5A@WeiGengyuPC> In-Reply-To: Date: Mon, 16 Nov 2015 06:41:18 +0530 Message-ID: <016901d1200b$b4d8c810$1e8a5830$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016A_01D12039.CE910410" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEb2TC8rtbUr7b8R2yKLLqcks4rrAEMnlnA Content-Language: en-us X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=W7WYLUik c=1 sm=1 tr=0 a=xIbZSC7ng2mmFQssLfPUfQ==:117 a=xIbZSC7ng2mmFQssLfPUfQ==:17 a=MKtGQD3n3ToA:10 a=ZZnuYtJkoWoA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=rXOfqY1BIzMAAsSseugA:9 a=jtlcRjE9qSpde2aS:21 a=GLEHNjgx0L-7fH8g:21 a=QEXdDO2ut3YA:10 a=z0VfwKaGnLwoagAVfGAA:9 a=DyfISkHqMmrQ4mXo:21 a=QbsYPpnkEqvA7i-2:21 a=gTX3H1VQiiyuDHL4:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 01:11:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_016A_01D12039.CE910410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Simon Lemay Sent: Tuesday, November 10, 2015 10:29 PM To: weigengyu; Core Subject: Re: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls =20 +1 for adoption=20 On Mon, Nov 9, 2015 at 05:34 weigengyu wrote: Hi all, =20 +1. It is important.=20 =20 And one question.=20 Does it need to give more specifications about the UDP-to-TCP and = TCP-to-UDP gateways?=20 =20 Regards, =20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications =20 From: Julien Vermillard =20 Sent: Sunday, November 08, 2015 3:14 PM To: Core =20 Subject: Re: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls =20 +1 =20 We suffer the same issues between our servers and our cellular modems. On some network we need to go down to 20 seconds. Julien =20 Le sam. 7 nov. 2015 22:17, Juan Perez a = =C3=A9crit : +1 =20 It is important for us (at Microsoft Azure IoT) that this document gets = adopted. Additionally, as part of the OMA LWM2M group, it=E2=80=99s = important that CoAP supports TCP/TLS as a standard to enable = internet/cloud scenarios. =20 =20 We=E2=80=99ve run tests between worldwide Azure and non-Azure data = centers and have found that a UDP keep-alive is required no more than = every 30 seconds in order to maintain reachability between clients and = servers. =20 =20 Thanks, Juan =20 From: Andrew Mcgregor [mailto:andrewmcgr@google.com]=20 Sent: Monday, November 2, 2015 8:38 PM To: Core Subject: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls =20 The sense of the room at IETF 94 was that we should adopt this as a = working group document. =20 This is the corresponding mailing list call, open until November 16. =20 Title : A TCP and TLS Transport for the Constrained = Application Protocol (CoAP) Authors : Carsten Bormann Simon Lemay Valik Solorzano Barboza Hannes Tschofenig Filename : draft-tschofenig-core-coap-tcp-tls-05.txt Pages : 12 Date : 2015-11-02 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-tschofenig-core-coap-tcp-tls/ There's also a htmlized version available at: = https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 A diff from the previous version is available at: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-tschofenig-core-coap-tcp-tls-05= =20 --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 _______________________________________________ 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 ------=_NextPart_000_016A_01D12039.CE910410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

From:= core [mailto:core-bounces@ietf.org] On Behalf Of Simon Lemay
Sent: Tuesday, November 10, 2015 10:29 PM
To: weigengyu; Core
Subject: Re: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls

 

+1 for adoption

On Mon, Nov 9, 2015 at 05:34 weigengyu <weigengyu@bupt.edu.cn> = wrote:

Hi all,

 

+1.  It is important.

 

And one question.

Does it need to give more specifications about the UDP-to-TCP and TCP-to-UDP gateways?

 

Regards,

 

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

 

Sent:= Sunday, November 08, 2015 3:14 PM

To:= Core

Subject:= = Re: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls

 

+1  =

We = suffer the same issues between our servers and our cellular modems.
On some network we need to go down to 20 seconds.

Julien

 

Le sam. 7 nov. 2015 22:17, Juan Perez <juanpere@microsoft.com> a =C3=A9crit = :

+1

 

It is important for us (at Microsoft Azure IoT) that this document gets adopted.  Additionally, as part of the OMA LWM2M group, = it=E2=80=99s important that CoAP supports TCP/TLS as a standard to enable internet/cloud scenarios. 

 

We=E2=80=99ve run tests between worldwide Azure and non-Azure data centers and have = found that a UDP keep-alive is required no more than every 30 seconds in order = to maintain reachability between clients and servers. 

 

Thanks,

Juan

 

From: Andrew Mcgregor [mailto:andrewmcgr@google.com]
Sent: Monday, November 2, 2015 8:38 PM
To: Core <core@ietf.org>
Subject: [core] Call for adoption of = draft-tschofenig-core-coap-tcp-tls

 

The sense of the room at IETF 94 was that we = should adopt this as a working group document.

 

This is the corresponding mailing list call, open = until November 16.

 

      = ;  Title           : A = TCP and TLS Transport for the Constrained Application Protocol (CoAP)
        Authors         : Carsten = Bormann
            &= nbsp;           &n= bsp; Simon Lemay
            &= nbsp;           &n= bsp; Valik Solorzano Barboza
            &= nbsp;           &n= bsp; Hannes Tschofenig
        Filename        : draft-tschofenig-core-coap-tcp-tls-05.txt
        Pages           : = 12
        Date            : 2015-11-02

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-tschofen= ig-core-coap-tcp-tls/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-tschofenig-co= re-coap-tcp-tls-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-tscho= fenig-core-coap-tcp-tls-05

 

--

Andrew McGregor | SRE = | andrewmcgr@google.com | +61 4 1071 2221

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

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

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

------=_NextPart_000_016A_01D12039.CE910410-- From nobody Sun Nov 15 19:44:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B541B2AF5 for ; Sun, 15 Nov 2015 19:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpFcV5QaRNsB for ; Sun, 15 Nov 2015 19:44:11 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76511B2AF2 for ; Sun, 15 Nov 2015 19:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tAG3i5Rm019740 for ; Mon, 16 Nov 2015 04:44:06 +0100 (CET) Received: from nar.local (p5DC7F6AE.dip0.t-ipconnect.de [93.199.246.174]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3nzbqT5QDTz2Ffn; Mon, 16 Nov 2015 04:44:05 +0100 (CET) Message-ID: <56495104.9030900@tzi.org> Date: Mon, 16 Nov 2015 04:44:04 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Core References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 03:44:13 -0000 I'm a co-author and I was in the room, but for the record I should probably also add that I'm in favor of adoption as a WG draft. Gr眉脽e, Carsten Andrew Mcgregor wrote: > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > Andrew McGregor | SRE | andrewmcgr@google.com > | +61 4 1071 2221 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 16 02:12:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1AC1B2FB6 for ; Mon, 16 Nov 2015 02:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.484 X-Spam-Level: X-Spam-Status: No, score=-7.484 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6isNORa_PPA for ; Mon, 16 Nov 2015 02:11:57 -0800 (PST) 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 7874F1B2FB5 for ; Mon, 16 Nov 2015 02:11:55 -0800 (PST) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.266.1; Mon, 16 Nov 2015 11:11:53 +0100 Received: from MBX110.d.ethz.ch ([fe80::9d9a:a7f2:c282:5f6a]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.03.0266.001; Mon, 16 Nov 2015 11:11:53 +0100 From: "Kovatsch Matthias" To: Andrew Mcgregor , Core Thread-Topic: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls Thread-Index: AQHRFfGDKZUNI788BU+1Y0L5HV5vdZ6egl0g Date: Mon, 16 Nov 2015 10:11:52 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B54DE25279@MBX110.d.ethz.ch> References: 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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B54DE25279MBX110dethzch_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 10:12:00 -0000 --_000_55877B3AFB359744BA0F2140E36F52B54DE25279MBX110dethzch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVzcGl0ZSBiZWluZyBhIGJpdCBsYXRlLCBJIGFsc28gc3VwcG9ydCB0aGUgYWRvcHRpb24gb2Yg dGhpcyBkb2N1bWVudC4NCg0KKzENCg0KTWF0dGhpYXMNCg0KRnJvbTogY29yZSBbbWFpbHRvOmNv cmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBNY2dyZWdvcg0KU2VudDog RGllbnN0YWcsIDMuIE5vdmVtYmVyIDIwMTUgMDU6MzgNClRvOiBDb3JlIDxjb3JlQGlldGYub3Jn Pg0KU3ViamVjdDogW2NvcmVdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LXRzY2hvZmVuaWct Y29yZS1jb2FwLXRjcC10bHMNCg0KVGhlIHNlbnNlIG9mIHRoZSByb29tIGF0IElFVEYgOTQgd2Fz IHRoYXQgd2Ugc2hvdWxkIGFkb3B0IHRoaXMgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K DQpUaGlzIGlzIHRoZSBjb3JyZXNwb25kaW5nIG1haWxpbmcgbGlzdCBjYWxsLCBvcGVuIHVudGls IE5vdmVtYmVyIDE2Lg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEEgVENQIGFuZCBUTFMg VHJhbnNwb3J0IGZvciB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVAp DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENhcnN0ZW4gQm9ybWFubg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBTaW1vbiBMZW1heQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBWYWxp ayBTb2xvcnphbm8gQmFyYm96YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBIYW5uZXMgVHNj aG9mZW5pZw0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC10c2Nob2ZlbmlnLWNvcmUt Y29hcC10Y3AtdGxzLTA1LnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiAxMg0KICAgICAg ICBEYXRlICAgICAgICAgICAgOiAyMDE1LTExLTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIEh5cGVy dGV4dCBUcmFuc2ZlciBQcm90b2NvbCAoSFRUUCkgd2FzIGRlc2lnbmVkIHdpdGggVENQIGFzIHRo ZQ0KICAgdW5kZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wuICBUaGUgQ29uc3RyYWluZWQgQXBw bGljYXRpb24gUHJvdG9jb2wNCiAgIChDb0FQKSwgd2hpbGUgaW5zcGlyZWQgYnkgSFRUUCwgaGFz IGJlZW4gZGVmaW5lZCB0byBtYWtlIHVzZSBvZiBVRFANCiAgIGluc3RlYWQgb2YgVENQLiAgVGhl cmVmb3JlLCByZWxpYWJsZSBkZWxpdmVyeSBhbmQgYSBzaW1wbGUgY29uZ2VzdGlvbg0KICAgY29u dHJvbCBhbmQgZmxvdyBjb250cm9sIG1lY2hhbmlzbSBhcmUgcHJvdmlkZWQgYnkgdGhlIG1lc3Nh Z2UgbGF5ZXINCiAgIG9mIHRoZSBDb0FQIHByb3RvY29sLg0KDQogICBBIG51bWJlciBvZiBlbnZp cm9ubWVudHMgYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2YgQ29BUCBkaXJlY3RseSBvdmVyIGENCiAg IHJlbGlhYmxlIGJ5dGUgc3RyZWFtIHN1Y2ggYXMgVENQLCB3aGljaCBhbHJlYWR5IHByb3ZpZGVz IHRoZXNlDQogICBzZXJ2aWNlcy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgdXNlIG9mIENv QVAgb3ZlciBUQ1AgYXMgd2VsbCBhcw0KICAgQ29BUCBvdmVyIFRMUy4NCg0KDQpUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRzY2hvZmVuaWctY29yZS1jb2FwLXRjcC10bHMvDQoN ClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctY29yZS1jb2FwLXRjcC10bHMtMDUN Cg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRzY2hvZmVuaWctY29yZS1jb2Fw LXRjcC10bHMtMDUNCg0KLS0NCkFuZHJldyBNY0dyZWdvciB8IFNSRSB8IGFuZHJld21jZ3JAZ29v Z2xlLmNvbTxtYWlsdG86YW5kcmV3bWNnckBnb29nbGUuY29tPiB8ICs2MSA0IDEwNzEgMjIyMQ0K --_000_55877B3AFB359744BA0F2140E36F52B54DE25279MBX110dethzch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkRFLUNIIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRl c3BpdGUgYmVpbmcgYSBiaXQgbGF0ZSwgSSBhbHNvIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NYXR0aGlhczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkFuZHJldyBNY2dyZWdvcjxicj4NCjxiPlNlbnQ6PC9iPiBEaWVuc3RhZywgMy4g Tm92ZW1iZXIgMjAxNSAwNTozODxicj4NCjxiPlRvOjwvYj4gQ29yZSAmbHQ7Y29yZUBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NvcmVdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRy YWZ0LXRzY2hvZmVuaWctY29yZS1jb2FwLXRjcC10bHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlbnNlIG9mIHRoZSByb29tIGF0IElF VEYgOTQgd2FzIHRoYXQgd2Ugc2hvdWxkIGFkb3B0IHRoaXMgYXMgYSB3b3JraW5nIGdyb3VwIGRv Y3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBpcyB0aGUgY29ycmVzcG9uZGluZyBtYWlsaW5nIGxpc3QgY2FsbCwgb3BlbiB1bnRpbCBOb3Zl bWJlciAxNi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEEg VENQIGFuZCBUTFMgVHJhbnNwb3J0IGZvciB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJv dG9jb2wgKENvQVApPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDYXJzdGVuIEJvcm1hbm48YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2ltb24gTGVtYXk8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVmFsaWsgU29sb3J6YW5vIEJhcmJvemE8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSGFubmVzIFRzY2hvZmVuaWc8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgOiBkcmFmdC10c2Nob2ZlbmlnLWNvcmUtY29hcC10Y3AtdGxzLTA1LnR4dDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiAxMjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE1LTExLTAyPGJyPg0K PGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBIeXBlcnRleHQgVHJhbnNmZXIg UHJvdG9jb2wgKEhUVFApIHdhcyBkZXNpZ25lZCB3aXRoIFRDUCBhcyB0aGU8YnI+DQombmJzcDsg Jm5ic3A7dW5kZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wuJm5ic3A7IFRoZSBDb25zdHJhaW5l ZCBBcHBsaWNhdGlvbiBQcm90b2NvbDxicj4NCiZuYnNwOyAmbmJzcDsoQ29BUCksIHdoaWxlIGlu c3BpcmVkIGJ5IEhUVFAsIGhhcyBiZWVuIGRlZmluZWQgdG8gbWFrZSB1c2Ugb2YgVURQPGJyPg0K Jm5ic3A7ICZuYnNwO2luc3RlYWQgb2YgVENQLiZuYnNwOyBUaGVyZWZvcmUsIHJlbGlhYmxlIGRl bGl2ZXJ5IGFuZCBhIHNpbXBsZSBjb25nZXN0aW9uPGJyPg0KJm5ic3A7ICZuYnNwO2NvbnRyb2wg YW5kIGZsb3cgY29udHJvbCBtZWNoYW5pc20gYXJlIHByb3ZpZGVkIGJ5IHRoZSBtZXNzYWdlIGxh eWVyPGJyPg0KJm5ic3A7ICZuYnNwO29mIHRoZSBDb0FQIHByb3RvY29sLjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDtBIG51bWJlciBvZiBlbnZpcm9ubWVudHMgYmVuZWZpdCBmcm9tIHRoZSB1c2Ug b2YgQ29BUCBkaXJlY3RseSBvdmVyIGE8YnI+DQombmJzcDsgJm5ic3A7cmVsaWFibGUgYnl0ZSBz dHJlYW0gc3VjaCBhcyBUQ1AsIHdoaWNoIGFscmVhZHkgcHJvdmlkZXMgdGhlc2U8YnI+DQombmJz cDsgJm5ic3A7c2VydmljZXMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgdXNlIG9m IENvQVAgb3ZlciBUQ1AgYXMgd2VsbCBhczxicj4NCiZuYnNwOyAmbmJzcDtDb0FQIG92ZXIgVExT Ljxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0 aGlzIGRyYWZ0IGlzOjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10c2Nob2ZlbmlnLWNvcmUtY29hcC10Y3AtdGxzLyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXRzY2hvZmVuaWctY29yZS1jb2FwLXRjcC10bHMvPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctY29yZS1jb2FwLXRjcC10 bHMtMDUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1jb3JlLWNvYXAtdGNwLXRs cy0wNTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGJyPg0KPGJyPg0K QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdHNj aG9mZW5pZy1jb3JlLWNvYXAtdGNwLXRscy0wNSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC10c2Nob2ZlbmlnLWNvcmUtY29hcC10Y3AtdGxzLTA1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNENTBGMjUg MS41cHQ7cGFkZGluZzoyLjBwdCI+QW5kcmV3IE1jR3JlZ29yJm5ic3A7fDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1 NTU1O2JvcmRlcjpzb2xpZCAjMzM2OUU4IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwO1NSRSZu YnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzAwOTkzOSAxLjVwdDtwYWRkaW5n OjIuMHB0Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86YW5kcmV3bWNnckBnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YW5kcmV3bWNnckBnb29nbGUuY29tPC9hPiZuYnNwO3w8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1 NTU1NTtib3JkZXI6c29saWQgI0VFQjIxMSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDsmIzQz OzYxDQogNCAxMDcxIDIyMjE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_55877B3AFB359744BA0F2140E36F52B54DE25279MBX110dethzch_-- From nobody Mon Nov 16 02:50:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678041A037B for ; Mon, 16 Nov 2015 02:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.928 X-Spam-Level: X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhBmgwjUHk-b for ; Mon, 16 Nov 2015 02:50:11 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDA31A0371 for ; Mon, 16 Nov 2015 02:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id tAGAo5EK024444 for ; Mon, 16 Nov 2015 11:50:05 +0100 (CET) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (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 3nznH06zT8z2GGQ for ; Mon, 16 Nov 2015 11:50:04 +0100 (CET) Received: by wmww144 with SMTP id w144so104359079wmw.1 for ; Mon, 16 Nov 2015 02:50:04 -0800 (PST) X-Received: by 10.28.228.138 with SMTP id b132mr19828441wmh.46.1447671004706; Mon, 16 Nov 2015 02:50:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.117.226 with HTTP; Mon, 16 Nov 2015 02:49:25 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B54DE25279@MBX110.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B54DE25279@MBX110.d.ethz.ch> From: Klaus Hartke Date: Mon, 16 Nov 2015 11:49:25 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Core Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 10:50:13 -0000 +1 Kovatsch Matthias wrote: > Despite being a bit late, I also support the adoption of this document. > > +1 > > Matthias From nobody Mon Nov 16 03:00:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C851A1A25 for ; Mon, 16 Nov 2015 03:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IANpYqIb2yhS for ; Mon, 16 Nov 2015 03:00:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7FD1A1A20 for ; Mon, 16 Nov 2015 03:00:21 -0800 (PST) Received: from [192.168.10.140] ([80.92.121.34]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M9vnQ-1a4r5K40Pw-00B3uB; Mon, 16 Nov 2015 12:00:07 +0100 To: Klaus Hartke , Core References: <55877B3AFB359744BA0F2140E36F52B54DE25279@MBX110.d.ethz.ch> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5649B734.1040800@gmx.net> Date: Mon, 16 Nov 2015 12:00:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r562iPBj91LtHR3DI0E7Jl0F9xThPrwaL" X-Provags-ID: V03:K0:koYX7Wj1QoK0emwdDjMMJZWVrLhSjsWvIHWO4OSvKekZsQVEcnr JTOWufD/9MKW5yZpLHNdUPCJ8DJZI+mdyPLIKl7MAaCf04v2UQkFS9koF/gGxVWsuhBoVkS 6e5xlaPJbo8y8fj1T/Dl0lrgg7t5Pr5Hrdkcq8kKlY50IZrjXJE5+B4dfvhGqwDiVZEYH36 qsPNxTpIHqu1pcI11Buww== X-UI-Out-Filterresults: notjunk:1;V01:K0:bc/+8PnIG2c=:fXB7Ay354UuCGnUGSsqcv4 l8mYhnEtvO4UZwYjzpOzY9vQHk727caiLnZ2I3c8Q5vm21xBvYTGDYMedJLW8gVsvRfJsKSSX U5FqUrSpyV+AzVdLvtfhRV6Ist1lUqMNjOSHQNXF6G9O8slSshmt9COSm/QpTnu9cw0l1qbX8 ijlZ2orV/mF+sXljZkeKbV5R02kSvSQSl49rCRY5IqeDq+fkEIARoa3bc23Fqo9MCGoWu37I/ 4AAIT53GlaHmkxNgAIy47rFdB7roLfvF1ONsRfRTpjU0w0sPu1zt2uPzU0DCdGJviod09rjJS oysNY45Ntjrznnt9ffeH6YvfsB/9Pa2E5mKisORLTN1VwJfxVLm2O+S02hEVOxtJ6cjliLyWB j0JASjtc/ldj/X2aZ8uuxzQYZcckruG4PAE4E4HW8/BstBCJ2+IRLDO5PFaQUBef6E47twnPK 8+xZzOfKBaFGupJW1R3KrZyKymEq3EffgJStJN4Yc6cut1NlwcJRqCXhQg0dKYCYyfYUKJg8K XA3HBq98nFqInz4mCUs3Tib1ogTyu3sf8B3C8m2DePOiQGj0KHPM/XK+Luycc/Ef0dM/1dcr5 z2S4dNkkUQfawkspz2z7Sh796LESVosdqxbfIWRSOYv8MFyAeL7B/M0eK4HpvWmF/F4L1Wutx X6N2q3JankygwOoyYhjkptCe+mRXh1OkFaQ04T34ONvJsOxCCoGeFkKsRXoh1cu1NLRYJuiX0 3SeoHQ5+b4R+VGatkQe/+WxtAb1LqmeGKm8DVMf8ntRk81H/07pOdGXSXrY= Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 11:00:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r562iPBj91LtHR3DI0E7Jl0F9xThPrwaL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 (Because we already implemented a variant of it.) On 11/16/2015 11:49 AM, Klaus Hartke wrote: > +1 >=20 > Kovatsch Matthias wrote: >> Despite being a bit late, I also support the adoption of this document= =2E >> >> +1 >> >> Matthias >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 --r562iPBj91LtHR3DI0E7Jl0F9xThPrwaL 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 iQEcBAEBCgAGBQJWSbc1AAoJEGhJURNOOiAtHBMH/A/cVzfYA/J7hjkAuq0h0kYh r9zV22yIVuIKSWiJPzuipfxmrkgP3802j3ecT5FA6oOc4UIwJAZ+T7VH/8A+TPg8 6TMDQERCvsyPNp5uJNIbFTBTswFUrGYsie76LwlFoNrdcERnArxwwNl4uk5GscHt e7VN0YjhluVDwNRMd1R+a75eZe+9+uUzKODG3B3hfRAiIcrylcZdN6Rg3AP+BS/s YLaRVTw8HdGToS+km0pZXzCrOjodwUW6cbOburCHBKtIDooaB7qdNonYXP/DF/Vh UDFRQB4yQBdI06W2zuNyWQzVtU5HEP3P4b6Wm2bVjuO95VgGNgR1gxDH6dJLLS0= =Hir9 -----END PGP SIGNATURE----- --r562iPBj91LtHR3DI0E7Jl0F9xThPrwaL-- From nobody Mon Nov 16 07:50:59 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008B51A1B59 for ; Mon, 16 Nov 2015 07:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMxiuBpDvZQm for ; Mon, 16 Nov 2015 07:50:56 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) (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 2337C1A1BA7 for ; Mon, 16 Nov 2015 07:50:53 -0800 (PST) Received: from [195.245.230.51] by server-12.bemta-3.messagelabs.com id BB/86-14900-45BF9465; Mon, 16 Nov 2015 15:50:44 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-10.tower-33.messagelabs.com!1447689043!941685!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27318 invoked from network); 16 Nov 2015 15:50:43 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-10.tower-33.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Nov 2015 15:50:43 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout01.vodafone.com (Postfix) with ESMTP id 3nzvxv4CyTz1yBX for ; Mon, 16 Nov 2015 16:50:43 +0100 (CET) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3nzvxv3H0TzxPgV for ; Mon, 16 Nov 2015 16:50:43 +0100 (CET) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3nzvxv3BpjzxP60 for ; Mon, 16 Nov 2015 16:50:43 +0100 (CET) Received: from VOEXC25W.internal.vodafone.com (145.230.103.197) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 16 Nov 2015 16:50:42 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.209]) by voexc25w ([145.230.103.197]) with mapi id 14.03.0224.002; Mon, 16 Nov 2015 16:50:41 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: "core@ietf.org" Thread-Topic: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls Thread-Index: AdEghhNKjDC/j31PTuqnUXqO53LE5g== Date: Mon, 16 Nov 2015 15:50:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 15:50:58 -0000 +1 for adoption Cheers Kevin Smith, Vodafone Group R&D=20 From nobody Tue Nov 17 01:41:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099221B2DB4 for ; Tue, 17 Nov 2015 01:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOq8154ePoA2 for ; Tue, 17 Nov 2015 01:41:08 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5571B2D7F for ; Tue, 17 Nov 2015 01:41:08 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud6.xs4all.net with ESMTP id iZh51r00K4h15BW01Zh5i1; Tue, 17 Nov 2015 10:41:06 +0100 Received: from [2001:983:a264:1:d101:57f:6aec:31da] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 17 Nov 2015 10:41:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Nov 2015 10:41:05 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> X-Sender: stokcons@xs4all.nl (G4+1JpDjZPOtx9cHt3jmVbtkB0G53ofY) User-Agent: XS4ALL Webmail Archived-At: Subject: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 09:41:11 -0000 Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into three parts as suggested by Juergen Schoenwalder in a separate earlier communication. This e_mail sets out in more detail why the proposed split is a good one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and CoMI. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it may be advisable to submit the draft to the netmod WG, where much of the YANG expertise exists and the draft can be aligned with the YANG to JSON draft. Ad ii and iii) These approaches are very different and merit independent drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts. It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and CoOL, may take some time. I will be happy if in Buenos Aires we have a list with issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org From nobody Tue Nov 17 07:51:53 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ADE1A1BDA for ; Tue, 17 Nov 2015 07:51:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWlOjYTQejMT for ; Tue, 17 Nov 2015 07:51:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECB51A1B7C for ; Tue, 17 Nov 2015 07:51:49 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 15:51:47 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) with mapi id 15.01.0325.003; Tue, 17 Nov 2015 15:51:47 +0000 From: Rodney Cummings To: peter van der Stok , Core Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwteQFUWYBvd0yDLSdmSQn7rZ6gWGHw Date: Tue, 17 Nov 2015 15:51:47 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.33] x-microsoft-exchange-diagnostics: 1; BN1PR04MB424; 5:KhsyRwHymA1Y1zF4aXsN13OCb/zOJ2gEX/S7XnJZ1Q6eako8LwfizmQcPVPLCBNYvQ4ePYyYfiLseobcBgbFgCxB9wvO9oqxZRTftZ7jBkzKe4TcUobe5fl/GjVm8MORoX2nw4qg4CyA2B4J/ffXrQ==; 24:JQqhuDFCUgKM0sQVdBGtq8AmLGwprpNrwQ4en3Dk/mEOx04l8I3XoO0tiX31nrIDN2IvmMY47rQaNGiQRCUJcA8hOjvV0vT5KYVKM//JS9s=; 20:0CBkI3XCQjWRhJP0dvEnK/xvyrlufhmukiWlOL0Hq4g4N4m8KUITBt5PpYkztI5Cd3m2rYodZwK2k7Ov+BBCRw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB424; 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)(520078)(10201501046)(3002001); SRVR:BN1PR04MB424; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB424; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(54094003)(377454003)(53754006)(189002)(199003)(40100003)(5007970100001)(5008740100001)(15975445007)(5004730100002)(5003600100002)(11100500001)(2950100001)(2900100001)(5002640100001)(102836002)(101416001)(50986999)(66066001)(76176999)(54356999)(19580395003)(107886002)(99286002)(97736004)(33656002)(105586002)(81156007)(5001770100001)(5001960100002)(189998001)(106356001)(106116001)(86362001)(19580405001)(5001920100001)(586003)(87936001)(92566002)(122556002)(74316001)(76576001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB424; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 15:51:47.0874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB424 Archived-At: Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:51:52 -0000 Thanks Peter, At this time, proceeding with 4 drafts sounds good to me. Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts: a) YANG to CBOR mapping ( i) ) b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that: 1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL. 2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective. 3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset). If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may hel= p to decide between hash/registry. If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale. Rodney -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Tuesday, November 17, 2015 3:41 AM To: Core Subject: [core] CoMI Cool draft splits Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts=20 into three parts as suggested by Juergen Schoenwalder in a separate=20 earlier communication. This e_mail sets out in more detail why the proposed split is a good=20 one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and=20 CoMI. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it=20 may be advisable to submit the draft to the netmod WG, where much of the=20 YANG expertise exists and the draft can be aligned with the YANG to JSON=20 draft. Ad ii and iii) These approaches are very different and merit independent=20 drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.=20 It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and=20 CoOL, may take some time. I will be happy if in Buenos Aires we have a=20 list with issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter --=20 Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Tue Nov 17 09:33:18 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E751A6EE2 for ; Tue, 17 Nov 2015 09:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N00BEOOC2Vgw for ; Tue, 17 Nov 2015 09:33:15 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 AFE461A6EE1 for ; Tue, 17 Nov 2015 09:33:14 -0800 (PST) Received: by lfs39 with SMTP id 39so10112576lfs.3 for ; Tue, 17 Nov 2015 09:33:12 -0800 (PST) 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:content-type; bh=eV9TYAc0DeKfI9f6s3ebksDpvmP3WOrAHUn2LoNPuSk=; b=TILyAnxCyUK2r70KnqZX9/F8Iyp6TAQ7d/ePOLnVikvGYT5/edU8SBn0Ze4oLtc1Z0 +Y6S550emVptl47nFFF0BkbSXkMykYKCRAerKCOXYYnVVrBPTnNYbQdcQRWlYGtg3qKO iuyS+E01re7LnzCatPzXSYdGVcSmxNACJQmzZDvinuO9Ncf7Bot0TOJyyAvjwABoqI5t Uuf63txfgeOVsviVIcfztjkcqrhEuKTsiUdxXIMsA3xO9FFUKzV9BRueiK78xmxkZCuF Hg/nP9JFKQke8XfH3rBOFhrjQRdd4gx42+ZSg0SWaBOtFm+o/0SfZb/Jr+XnHNed8atJ 8WFw== 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:content-type; bh=eV9TYAc0DeKfI9f6s3ebksDpvmP3WOrAHUn2LoNPuSk=; b=SjUerN0si/Wz9EAxe/kVn74ZoXZ8iSZXfxMTCp9f785tptBYdnkbgzdA5CuvWDk7l5 m9upyvBf967K3AHYe6weP77SgTfX+eBubW1V3LOiT6GjY5jT05SaR4VEyOsAjk0gfFSE 8fmZo8zXATIAbpCP6oYBYS0c2L5gdZ1Kctouar2Hx686CgzsOQ9TtOwALpPO1JastefY FmTAWfMyd9M+HOnymkCjd76fQ7vc32rSpPu/u3neD2VqFrzEvwvCSQ+btDyiRneC8xUG zThiL1WwEii4P5+29u6LJKELb6+Dvo68vxcrcBt+4Njv67Hl+pDomldR8jHc/2/hTaYg RqxA== X-Gm-Message-State: ALoCoQkhkWgCL1KQCEDkikJD+H0EzoCc9udfPlwAETGtWDlLXqZPo1za2WV2uB7J4JAxFLGpmS0a MIME-Version: 1.0 X-Received: by 10.25.18.209 with SMTP id 78mr20548059lfs.54.1447781592713; Tue, 17 Nov 2015 09:33:12 -0800 (PST) Received: by 10.112.144.106 with HTTP; Tue, 17 Nov 2015 09:33:12 -0800 (PST) In-Reply-To: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Date: Tue, 17 Nov 2015 09:33:12 -0800 Message-ID: From: Andy Bierman To: Rodney Cummings Content-Type: multipart/alternative; boundary=001a114065e88be48c0524bfebf1 Archived-At: Cc: peter van der Stok , Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:33:17 -0000 --001a114065e88be48c0524bfebf1 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 17, 2015 at 7:51 AM, Rodney Cummings wrote: > Thanks Peter, > > At this time, proceeding with 4 drafts sounds good to me. > > Nevertheless, as we get closer to progressing these in a WG, I think we > should transition to 2 drafts: > a) YANG to CBOR mapping ( i) ) > b) Select either hash ( ii) ) or registry ( iii) ), and merge that with > the function set ( iv) ) for a single draft > > I think the YANG Hash draft should be separate from the protocol. We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > As for the motivation and use cases, I wonder if it might be helpful to > state our assumptions for the client side. I would claim that: > 1. A client cannot assume that the YANG modules implemented by the server > have been enhanced specifically for CoMI/CoOL. > 2. A client cannot assume that the YANG objects of a module are distinct > from a hashing perspective. > 3. A client cannot assume that a new revision of a module is backward > compatible to an older revision of that module (i.e. old is proper subset). > If these assumptions are correct, then the client must perform some > processing of the server's YANG modules prior to using CoMI/CoOL, and that > may help to decide between hash/registry. > If these assumptions are incorrect, it might be useful to discuss it in > the draft, to provide some background rationale. > I do not think manual management of YANG object identifiers is a workable design. It assumes that all modules will be registered with some centralized naming authority. I do not see how every module will be registered. This means unregistered modules cannot be used at all. The manual numbering also has a hard-limit of 1024 objects per YANG module. If a module ever has more than 1024 nodes, the "extra" nodes are unusable. It can be very difficult to manually number objects: module A { grouping A1 { leaf X { ... } leaf Y { ... } } } module B { import A { prefix A1; } container B1 { uses A:A1; } leaf B2 { ... } } NEXT RELEASE: module A { grouping A1 { leaf X { ... } leaf Y { ... } leaf Z { ... } } } If the grouping A:A1 is ever extended, there is no way to number the new objects in module B. All objects after the "uses A:A1" will renumber if new nodes are added to the external grouping (which is broken!) Since this is a very common usage scenario in YANG, this problem will happen a lot over time. YANG Hash has the complexity of identifying the hash collision and reading the rehash mapping info. Manual numbering has the complexity of managing the numbering space and dealing with unregistered modules. I don't see how a client would make this hash vs. managed numbers decision at run-time. It is not as if the CoMI server will provide multiple ways of numbering objects. Giant routers do not even do that, let alone constrained devices. Unless CoMI uses unmodified YANG modules, it does not really support YANG. > Rodney > > Andy > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok > Sent: Tuesday, November 17, 2015 3:41 AM > To: Core > Subject: [core] CoMI Cool draft splits > > Hi all, > > During the Yokohama meeting I proposed to split the CoMI/CoOl drafts > into three parts as suggested by Juergen Schoenwalder in a separate > earlier communication. > This e_mail sets out in more detail why the proposed split is a good > one. > > The proposed three parts are: > 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) > 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) > 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) > > The split has two advantages: > - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF > - It separates out the issues which need to be solved to merge CoOL and > CoMI. > > I come to the generation of 4 drafts: > i) The YANG to CBOR mapping. > ii) Hashing of YANG names > iii) Managed identifier assignment to YANG names > iv) The Function set specification > > Ad i) I don't expect a long list of issues for the merging. However, it > may be advisable to submit the draft to the netmod WG, where much of the > YANG expertise exists and the draft can be aligned with the YANG to JSON > draft. > Ad ii and iii) These approaches are very different and merit independent > drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts. > It is also possible that drafts get submitted to other WGs. > Ad iv) In my view the alignment of the two existing approaches, CoMI and > CoOL, may take some time. I will be happy if in Buenos Aires we have a > list with issues, accompanying motivation, and use cases. > > Is this a valid approach? Comments are solicited. > > Peter > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > > _______________________________________________ > 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 > --001a114065e88be48c0524bfebf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 17, 2015 at 7:51 AM, Rodney Cummings <= rodney.cummings= @ni.com> wrote:
Thanks Peter,

At this time, proceeding with 4 drafts sounds good to me.

Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts:
a) YANG to CBOR mapping ( i) )
b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft



I think the YANG Hash d= raft should be separate from the protocol.
We want to use it with= RESTCONF, as well as the YANG/CBOR encoding.

=C2= =A0
As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that:
1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL.
2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective.
3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset).
If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may= help to decide between hash/registry.
If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale.


I do not think manual management of YANG object ident= ifiers is
a workable design.=C2=A0 It assumes that all modules wi= ll be registered
with some centralized naming authority.=C2=A0 I = do not see how every module
will be registered.=C2=A0 This means = unregistered modules cannot be used at all.
The manual numbering = also has a hard-limit of 1024 objects per YANG module.
If a modul= e ever has more than 1024 nodes, the "extra" nodes are unusable.<= /div>

It can be very difficult to manually number object= s:

module A {
=C2=A0 =C2=A0grouping A1 {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { ... }
=C2=A0 =C2= =A0 =C2=A0 =C2=A0leaf Y { ... }
=C2=A0 =C2=A0 }
}
=

module B {
=C2=A0 =C2=A0import A { prefix A1;= }

=C2=A0 =C2=A0container B1 {
=C2=A0 = =C2=A0 =C2=A0uses A:A1;
=C2=A0 =C2=A0}
=C2=A0 =C2=A0lea= f B2 { ... }
}


NEXT RELEA= SE:

module A {
=C2=A0 =C2=A0groupin= g A1 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { ... }
=C2=A0= =C2=A0 =C2=A0 =C2=A0leaf Y { ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0le= af Z { ... }
=C2=A0 =C2=A0 }
}


If the grouping A:A1 is ever extended, there is no wa= y to number the new objects
in module B.=C2=A0 All objects after = the "uses A:A1" will renumber if new nodes are
added to= the external grouping (which is broken!)
Since this is a very co= mmon usage scenario in YANG, this problem will
happen a lot over = time.

YANG Hash has the complexity of identifying = the hash collision and reading
the rehash mapping info.=C2=A0 Man= ual numbering has the complexity of managing
the numbering space = and dealing with unregistered modules.

I don't= see how a client would make this hash vs. managed numbers decision at run-= time.
It is not as if the CoMI server will provide multiple ways = of numbering objects.
Giant routers do not even do that, let alon= e constrained devices.

Unless CoMI uses unmodified= YANG modules, it does not really support YANG.


Rodney


Andy
=C2=A0
-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of peter van der Stok
Sent: Tuesday, November 17, 2015 3:41 AM
To: Core <core@ietf.org>
Subject: [core] CoMI Cool draft splits

Hi all,

During the Yokohama meeting I proposed to split the CoMI/CoOl drafts
into three parts as suggested by Juergen Schoenwalder in a separate
earlier communication.
This e_mail sets out in more detail why the proposed split is a good
one.

The proposed three parts are:
1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL)
3) The YANG name compression (section 5 in CoMI; section 6 in CoOL)

The split has two advantages:
- the parts 2 and 3 can be used in other contexts, e.g. RESTCONF
- It separates out the issues which need to be solved to merge CoOL and
CoMI.

I come to the generation of 4 drafts:
i) The YANG to CBOR mapping.
ii) Hashing of YANG names
iii) Managed identifier assignment to YANG names
iv) The Function set specification

Ad i) I don't expect a long list of issues for the merging. However, it=
may be advisable to submit the draft to the netmod WG, where much of the YANG expertise exists and the draft can be aligned with the YANG to JSON draft.
Ad ii and iii) These approaches are very different and merit independent drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts. It is also possible that drafts get submitted to other WGs.
Ad iv) In my view the alignment of the two existing approaches, CoMI and CoOL, may take some time. I will be happy if in Buenos Aires we have a
list with issues, accompanying motivation, and use cases.

Is this a valid approach? Comments are solicited.

Peter

--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vandersto= k.org

_______________________________________________
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

--001a114065e88be48c0524bfebf1-- From nobody Tue Nov 17 11:19:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128191A6F9B for ; Tue, 17 Nov 2015 11:19:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTck-eBA3_KZ for ; Tue, 17 Nov 2015 11:19:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3781A6F9C for ; Tue, 17 Nov 2015 11:19:22 -0800 (PST) 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.325.17; Tue, 17 Nov 2015 19:19:19 +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.0325.003; Tue, 17 Nov 2015 19:19:19 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbWsbLKAGX5UGJtJafdAsAuZ6gYVTA Date: Tue, 17 Nov 2015 19:19:19 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:qoA+0PzSb9NyGV2KWIICmk6T0a5FbflqFfAyyahmaewgsEQ8kI+boP/TY/maOnn3UY4rzWxvMlKoab0xqOJGQGNh2sOgyTtwgt3o6gbs3E9FzzWu5KGNqVMx+LQJasLCpC8M/zdf2HIHx0G24TinJw==; 24:iLhSPJdpo7/mZLWWNaPWWsti0uJzXtmxI0jxk7YmFDqXwALzZElNRsVma9C0i4N5jA8RTFQD5Xr1YPERWSpLCQV2Z1bRpzJd5Vr8d03RaVo=; 20:Kg8NMYUdiwCrXwWaiPMWBAIyb8IzHEsBT8f6O5YcvLIKZ1KfSIJ2SzJToa1vIQTO/bs7qcpuDndLYvGxrH/9rA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(53754006)(189002)(38414003)(377454003)(199003)(122556002)(586003)(92566002)(40100003)(74316001)(81156007)(2501003)(76576001)(5001770100001)(97736004)(5890100001)(19580395003)(54356999)(19580405001)(76176999)(5008740100001)(50986999)(5004730100002)(99936001)(77096005)(66066001)(5001960100002)(99286002)(5007970100001)(102836002)(15975445007)(5001920100001)(106116001)(11100500001)(10400500002)(106356001)(105586002)(2900100001)(2950100001)(5003600100002)(101416001)(15974865002)(86362001)(33656002)(87936001)(189998001)(5002640100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_003_BLUPR06MB1763F35D73A9ED9A451915BDFE1D0BLUPR06MB1763namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 19:19:19.4613 (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] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 19:19:25 -0000 --_003_BLUPR06MB1763F35D73A9ED9A451915BDFE1D0BLUPR06MB1763namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter The 4 drafts you propose make lots of sense. I propose to start by the item 'I' (The YANG to CBOR mapping), follow by it= em 'iv' (The Function set specification), follow by items 'II' and 'III'. I propose this order since examples in the latter will be based on the firs= t two deliverables. I have extracted section 4 and 5 of the CoOL draft as starting point, see a= ttachments. Do you accept this contribution as strawman for this work? Should we create a specific mailing list for this work? Regards, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com =A0=20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: November-17-15 4:41 AM To: Core Subject: [core] CoMI Cool draft splits Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into t= hree parts as suggested by Juergen Schoenwalder in a separate earlier commu= nication. This e_mail sets out in more detail why the proposed split is a good one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and CoM= I. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it may= be advisable to submit the draft to the netmod WG, where much of the YANG = expertise exists and the draft can be aligned with the YANG to JSON draft. Ad ii and iii) These approaches are very different and merit independent dr= afts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.=20 It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and Co= OL, may take some time. I will be happy if in Buenos Aires we have a list w= ith issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_003_BLUPR06MB1763F35D73A9ED9A451915BDFE1D0BLUPR06MB1763namp_ Content-Type: application/xml; name="draft-ietf-core-yang-cbor-mapping-00-r01.xml" Content-Description: draft-ietf-core-yang-cbor-mapping-00-r01.xml Content-Disposition: attachment; filename="draft-ietf-core-yang-cbor-mapping-00-r01.xml"; size=30666; creation-date="Tue, 10 Nov 2015 22:10:50 GMT"; modification-date="Tue, 10 Nov 2015 22:10:50 GMT" Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4NCjwhLS0gVGhpcyB0ZW1w bGF0ZSBpcyBmb3IgY3JlYXRpbmcgYW4gSW50ZXJuZXQgRHJhZnQgdXNpbmcgeG1sMnJmYywNCiAg ICAgd2hpY2ggaXMgYXZhaWxhYmxlIGhlcmU6IGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLiAtLT4N CjwhRE9DVFlQRSByZmMgU1lTVEVNICJyZmMyNjI5LmR0ZCIgWw0KPCEtLSBPbmUgbWV0aG9kIHRv IGdldCByZWZlcmVuY2VzIGZyb20gdGhlIG9ubGluZSBjaXRhdGlvbiBsaWJyYXJpZXMuDQogICAg IFRoZXJlIGhhcyB0byBiZSBvbmUgZW50aXR5IGZvciBlYWNoIGl0ZW0gdG8gYmUgcmVmZXJlbmNl ZC4gDQogICAgIEFuIGFsdGVybmF0ZSBtZXRob2QgKHJmYyBpbmNsdWRlKSBpcyBkZXNjcmliZWQg aW4gdGhlIHJlZmVyZW5jZXMuIC0tPg0KDQoNCjwhRU5USVRZIFJGQzIxMTkgU1lTVEVNICJodHRw Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjIxMTku eG1sIj4NCjwhRU5USVRZIFJGQzYwMjAgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjYwMjAueG1sIj4NCjwhRU5USVRZIFJGQzcw NDkgU1lTVEVNICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZl cmVuY2UuUkZDLjcwNDkueG1sIj4NCjwhRU5USVRZIFJGQzcxNTkgU1lTVEVNICJodHRwOi8veG1s LnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2UuUkZDLjcxNTkueG1sIj4N Cg0KPCFFTlRJVFkgUkZDNzIyMyBTWVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNzIyMy54bWwiPg0KPCFFTlRJVFkgUkZDNzI3NyBT WVNURU0gImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5j ZS5SRkMuNzI3Ny54bWwiPg0KPCFFTlRJVFkgUkZDNzMxNyBTWVNURU0gImh0dHA6Ly94bWwucmVz b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNzMxNy54bWwiPg0KCl0+ DQo8P3htbC1zdHlsZXNoZWV0IHR5cGU9J3RleHQveHNsJyBocmVmPSdyZmMyNjI5LnhzbHQnID8+ DQo8IS0tIHVzZWQgYnkgWFNMVCBwcm9jZXNzb3JzIC0tPg0KPCEtLSBGb3IgYSBjb21wbGV0ZSBs aXN0IGFuZCBkZXNjcmlwdGlvbiBvZiBwcm9jZXNzaW5nIGluc3RydWN0aW9ucyAoUElzKSwgDQog ICAgIHBsZWFzZSBzZWUgaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvYXV0aG9yaW5nL1JFQURNRS5o dG1sLiAtLT4NCjwhLS0gQmVsb3cgYXJlIGdlbmVyYWxseSBhcHBsaWNhYmxlIFByb2Nlc3Npbmcg SW5zdHJ1Y3Rpb25zIChQSXMpIHRoYXQgbW9zdCBJLURzIG1pZ2h0IHdhbnQgdG8gdXNlLg0KICAg ICAoSGVyZSB0aGV5IGFyZSBzZXQgZGlmZmVyZW50bHkgdGhhbiB0aGVpciBkZWZhdWx0cyBpbiB4 bWwycmZjIHYxLjMyKSAtLT4NCjw/cmZjIHN0cmljdD0ieWVzIiA/Pg0KPCEtLSBnaXZlIGVycm9y cyByZWdhcmRpbmcgSUQtbml0cyBhbmQgRFREIHZhbGlkYXRpb24gLS0+DQo8IS0tIGNvbnRyb2wg dGhlIHRhYmxlIG9mIGNvbnRlbnRzIChUb0MpIC0tPg0KPD9yZmMgdG9jPSJ5ZXMiPz4NCjwhLS0g Z2VuZXJhdGUgYSBUb0MgLS0+DQo8P3JmYyB0b2NkZXB0aD0iNCI/Pg0KPCEtLSB0aGUgbnVtYmVy IG9mIGxldmVscyBvZiBzdWJzZWN0aW9ucyBpbiBUb0MuIGRlZmF1bHQ6IDMgLS0+DQo8IS0tIGNv bnRyb2wgcmVmZXJlbmNlcyAtLT4NCjw/cmZjIHN5bXJlZnM9InllcyI/Pg0KPCEtLSB1c2Ugc3lt Ym9saWMgcmVmZXJlbmNlcyB0YWdzLCBpLmUsIFtSRkMyMTE5XSBpbnN0ZWFkIG9mIFsxXSAtLT4N Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiID8+DQo8IS0tIHNvcnQgdGhlIHJlZmVyZW5jZSBlbnRyaWVz IGFscGhhYmV0aWNhbGx5IC0tPg0KPCEtLSBjb250cm9sIHZlcnRpY2FsIHdoaXRlIHNwYWNlIA0K ICAgICAodXNpbmcgdGhlc2UgUElzIGFzIGZvbGxvd3MgaXMgcmVjb21tZW5kZWQgYnkgdGhlIFJG QyBFZGl0b3IpIC0tPg0KPD9yZmMgY29tcGFjdD0ieWVzIiA/Pg0KPCEtLSBkbyBub3Qgc3RhcnQg ZWFjaCBtYWluIHNlY3Rpb24gb24gYSBuZXcgcGFnZSAtLT4NCjw/cmZjIHN1YmNvbXBhY3Q9Im5v IiA/Pg0KPCEtLSBrZWVwIG9uZSBibGFuayBsaW5lIGJldHdlZW4gbGlzdCBpdGVtcyAtLT4NCjwh LS0gZW5kIG9mIGxpc3Qgb2YgcG9wdWxhciBJLUQgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMgLS0+ DQo8cmZjIGNhdGVnb3J5PSJpbmZvIiBkb2NOYW1lPSJpZXRmLWNvcmUteWFuZy1jYm9yLW1hcHBp bmciIGlwcj0idHJ1c3QyMDA5MDIiPg0KICA8IS0tIGNhdGVnb3J5IHZhbHVlczogc3RkLCBiY3As IGluZm8sIGV4cCwgYW5kIGhpc3RvcmljDQogICAgIGlwciB2YWx1ZXM6IGZ1bGwzNjY3LCBub01v ZGlmaWNhdGlvbjM2NjcsIG5vRGVyaXZhdGl2ZXMzNjY3DQogICAgIHlvdSBjYW4gYWRkIHRoZSBh dHRyaWJ1dGVzIHVwZGF0ZXM9Ik5OTk4iIGFuZCBvYnNvbGV0ZXM9Ik5OTk4iIA0KICAgICB0aGV5 IHdpbGwgYXV0b21hdGljYWxseSBiZSBvdXRwdXQgd2l0aCAiKGlmIGFwcHJvdmVkKSIgLS0+DQoN CiAgPCEtLSAqKioqKiBGUk9OVCBNQVRURVIgKioqKiogLS0+DQoNCiAgPGZyb250Pg0KICAgIDwh LS0gVGhlIGFiYnJldmlhdGVkIHRpdGxlIGlzIHVzZWQgaW4gdGhlIHBhZ2UgaGVhZGVyIC0gaXQg aXMgb25seSBuZWNlc3NhcnkgaWYgdGhlIA0KICAgICAgICAgZnVsbCB0aXRsZSBpcyBsb25nZXIg dGhhbiAzOSBjaGFyYWN0ZXJzIGFiYnJldj0iQWJicmV2aWF0ZWQgVGl0bGUiIC0tPg0KDQogICAg PHRpdGxlPkNCT1IgRW5jb2Rpbmcgb2YgRGF0YSBNb2RlbGVkIHdpdGggWUFORzwvdGl0bGU+DQog ICAgDQogICAgPGF1dGhvciBmdWxsbmFtZT0iTWljaGVsIFZlaWxsZXR0ZSIgaW5pdGlhbHM9Ik0u Vi4iIHJvbGU9ImVkaXRvciIgc3VybmFtZT0iVmVpbGxldHRlIj4NCiAgICAgIDxvcmdhbml6YXRp b24+VHJpbGxpYW50IE5ldHdvcmtzIEluYy48L29yZ2FuaXphdGlvbj4NCg0KICAgICAgPGFkZHJl c3M+DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPCEtLSBSZW9yZGVyIHRoZXNlIGlmIHlv dXIgY291bnRyeSBkb2VzIHRoaW5ncyBkaWZmZXJlbnRseSAtLT4NCiAgICAgICAgICA8c3RyZWV0 PjYxMCBSdWUgZHUgTHV4ZW1ib3VyZzwvc3RyZWV0Pg0KICAgICAgICAgIDxjb2RlPkoySiAyVjI8 L2NvZGU+DQogICAgICAgICAgPGNpdHk+R3JhbmJ5PC9jaXR5Pg0KICAgICAgICAgIDxyZWdpb24+ UXVlYmVjPC9yZWdpb24+DQogICAgICAgICAgPGNvdW50cnk+Q2FuYWRhPC9jb3VudHJ5Pg0KICAg ICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPHBob25lPisxNDUwMzc1MDU1NjwvcGhvbmU+DQogICAg ICAgIDxlbWFpbD5taWNoZWwudmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208L2VtYWlsPg0KICAg ICAgPC9hZGRyZXNzPg0KICAgIDwvYXV0aG9yPg0KICAgIA0KICAgIDxhdXRob3IgZnVsbG5hbWU9 IkFsZXhhbmRlciBQZWxvdiIgaW5pdGlhbHM9IkEuUC4iIHJvbGU9ImVkaXRvciIgc3VybmFtZT0i UGVsb3YiPg0KICAgICAgPG9yZ2FuaXphdGlvbj5BY2tsaW88L29yZ2FuaXphdGlvbj4NCg0KICAg ICAgPGFkZHJlc3M+DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPCEtLSBSZW9yZGVyIHRo ZXNlIGlmIHlvdXIgY291bnRyeSBkb2VzIHRoaW5ncyBkaWZmZXJlbnRseSAtLT4NCiAgICAgICAg ICA8c3RyZWV0PjIgUnVlIGRlIGxhIENoYXRhaWduZXJhaWU8L3N0cmVldD4NCiAgICAgICAgICA8 Y29kZT4zNTUxMDwvY29kZT4NCiAgICAgICAgICA8Y2l0eT5DZXNzb24tU2V2aWduZTwvY2l0eT4N CiAgICAgICAgICA8cmVnaW9uPkJyZXRhZ25lPC9yZWdpb24+DQogICAgICAgICAgPGNvdW50cnk+ RnJhbmNlPC9jb3VudHJ5Pg0KICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPHBob25lPiszMzI5 OTEyNzAwNDwvcGhvbmU+DQogICAgICAgIDxlbWFpbD5hQGFja2wuaW88L2VtYWlsPg0KICAgICAg PC9hZGRyZXNzPg0KICAgIDwvYXV0aG9yPg0KDQogICAgPGF1dGhvciBmdWxsbmFtZT0iQWJoaW5h diBTb21hcmFqdSIgaW5pdGlhbHM9IkEuIFMuIiBzdXJuYW1lPSJTb21hcmFqdSI+DQogICAgICA8 b3JnYW5pemF0aW9uPlRyaWRvbmljIEdtYkggJmFtcDsgQ28gS0c8L29yZ2FuaXphdGlvbj4NCiAg ICAgIDxhZGRyZXNzPg0KICAgICAgICA8cG9zdGFsPg0KICAgICAgICAgIDwhLS0gUmVvcmRlciB0 aGVzZSBpZiB5b3VyIGNvdW50cnkgZG9lcyB0aGluZ3MgZGlmZmVyZW50bHkgLS0+DQogICAgICAg ICAgPHN0cmVldD5GYXJiZXJnYXNzZSAxNTwvc3RyZWV0Pg0KICAgICAgICAgIDxjb2RlPjY4NTA8 L2NvZGU+DQogICAgICAgICAgPGNpdHk+RG9ybmJpcm48L2NpdHk+DQogICAgICAgICAgPHJlZ2lv bj5Wb3JhcmxiZXJnPC9yZWdpb24+DQogICAgICAgICAgPGNvdW50cnk+QXVzdHJpYTwvY291bnRy eT4NCiAgICAgICAgPC9wb3N0YWw+DQogICAgICAgIDxwaG9uZT4rNDM2NjQ4MDg5MjYxNjk8L3Bo b25lPg0KICAgICAgICA8ZW1haWw+YWJoaW5hdi5zb21hcmFqdUB0cmlkb25pYy5jb208L2VtYWls Pg0KICAgICAgPC9hZGRyZXNzPg0KICAgIDwvYXV0aG9yPg0KDQogICAgPGF1dGhvciBmdWxsbmFt ZT0iUmFuZHkgVHVybmVyIiBpbml0aWFscz0iUi5ULiIgc3VybmFtZT0iVHVybmVyIj4NCiAgICAg IDxvcmdhbml6YXRpb24+TGFuZGlzK0d5cjwvb3JnYW5pemF0aW9uPg0KICAgICAgPGFkZHJlc3M+ DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPCEtLSBSZW9yZGVyIHRoZXNlIGlmIHlvdXIg Y291bnRyeSBkb2VzIHRoaW5ncyBkaWZmZXJlbnRseSAtLT4NCiAgICAgICAgICA8c3RyZWV0PjMw MDAwIE1pbGwgQ3JlZWsgQXZlPC9zdHJlZXQ+DQogICAgICAgICAgPHN0cmVldD5TdWl0ZSAxMDA8 L3N0cmVldD4NCiAgICAgICAgICA8Y29kZT4zMDAyMjwvY29kZT4NCiAgICAgICAgICA8Y2l0eT5B bHBoYXJldHRhPC9jaXR5Pg0KICAgICAgICAgIDxyZWdpb24+R0E8L3JlZ2lvbj4NCiAgICAgICAg ICA8Y291bnRyeT5VUzwvY291bnRyeT4NCiAgICAgICAgPC9wb3N0YWw+DQogICAgICAgIDxwaG9u ZT4rKzE2NzgyNTgxMjkyPC9waG9uZT4NCiAgICAgICAgPGVtYWlsPnJhbmR5LnR1cm5lckBsYW5k aXNneXIuY29tPC9lbWFpbD4NCgkJPHVyaT5odHRwOi8vd3d3LmxhbmRpc2d5ci5jb20vPC91cmk+ DQogICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+DQoNCiAgICA8YXV0aG9yIGZ1bGxuYW1l PSJBbmR5IEJpZXJtYW4iIGluaXRpYWxzPSJBLkIuIiBzdXJuYW1lPSJCaWVybWFuIj4NCiAgICAg IDxvcmdhbml6YXRpb24+WXVtYVdvcmtzPC9vcmdhbml6YXRpb24+DQogICAgICA8YWRkcmVzcz4N CiAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICA8IS0tIFJlb3JkZXIgdGhlc2UgaWYgeW91ciBj b3VudHJ5IGRvZXMgdGhpbmdzIGRpZmZlcmVudGx5IC0tPg0KICAgICAgICAgIDxzdHJlZXQ+Njg1 IENvY2hyYW4gU3QuPC9zdHJlZXQ+DQogICAgICAgICAgPHN0cmVldD5TdWl0ZSAjMTYwPC9zdHJl ZXQ+DQogICAgICAgICAgPGNvZGU+OTMwNjU8L2NvZGU+DQogICAgICAgICAgPGNpdHk+U2ltaSBW YWxsZXk8L2NpdHk+DQogICAgICAgICAgPHJlZ2lvbj5DQTwvcmVnaW9uPg0KICAgICAgICAgIDxj b3VudHJ5PlVTPC9jb3VudHJ5Pg0KICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPGVtYWlsPmFu ZHlAeXVtYXdvcmtzLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+ DQoNCiAgICA8YXV0aG9yIGZ1bGxuYW1lPSJQZXRlciB2YW4gZGVyIFN0b2siIGluaXRpYWxzPSJQ LlYuIiBzdXJuYW1lPSJ2YW4gZGVyIFN0b2siPg0KICAgICAgPG9yZ2FuaXphdGlvbj5Db25zdWx0 YW50PC9vcmdhbml6YXRpb24+DQogICAgICA8YWRkcmVzcz4NCiAgICAgICAgPHBob25lPiszMS00 OTI0NzQ2NzMgKE5ldGhlcmxhbmRzKSwgKzMzLTk2NjAxNTI0OCAoRnJhbmNlKTwvcGhvbmU+DQog ICAgICAgIDxlbWFpbD5jb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZzwvZW1haWw+DQoJCTx1cmk+ aHR0cDovL3d3dy52YW5kZXJzdG9rLm9yZy88L3VyaT4NCiAgICAgIDwvYWRkcmVzcz4NCiAgICA8 L2F1dGhvcj4NCg0KICAgIDxkYXRlLz4NCiAgICA8IS0tIGRhdGUgbW9udGg9Ik1hcmNoIiB5ZWFy PSIyMDA3IiAvIC0tPg0KDQogICAgPCEtLSBJZiB0aGUgbW9udGggYW5kIHllYXIgYXJlIGJvdGgg c3BlY2lmaWVkIGFuZCBhcmUgdGhlIGN1cnJlbnQgb25lcywgeG1sMnJmYyB3aWxsIGZpbGwgDQog ICAgICAgICBpbiB0aGUgY3VycmVudCBkYXkgZm9yIHlvdS4gSWYgb25seSB0aGUgY3VycmVudCB5 ZWFyIGlzIHNwZWNpZmllZCwgeG1sMnJmYyB3aWxsIGZpbGwgDQogICBpbiB0aGUgY3VycmVudCBk YXkgYW5kIG1vbnRoIGZvciB5b3UuIElmIHRoZSB5ZWFyIGlzIG5vdCB0aGUgY3VycmVudCBvbmUs IGl0IGlzIA0KICAgbmVjZXNzYXJ5IHRvIHNwZWNpZnkgYXQgbGVhc3QgYSBtb250aCAoeG1sMnJm YyBhc3N1bWVzIGRheT0iMSIgaWYgbm90IHNwZWNpZmllZCBmb3IgdGhlIA0KICAgcHVycG9zZSBv ZiBjYWxjdWxhdGluZyB0aGUgZXhwaXJ5IGRhdGUpLiAgV2l0aCBkcmFmdHMgaXQgaXMgbm9ybWFs bHkgc3VmZmljaWVudCB0byANCiAgIHNwZWNpZnkganVzdCB0aGUgeWVhci4gLS0+DQoNCiAgICA8 IS0tIE1ldGEtZGF0YSBEZWNsYXJhdGlvbnMgLS0+DQoNCiAgICA8YXJlYT5BcHBsaWNhdGlvbnMg YW5kIFJlYWwtVGltZSBBcmVhIChhcnQpPC9hcmVhPg0KDQogICAgPHdvcmtncm91cD5JbnRlcm5l dCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlPC93b3JrZ3JvdXA+DQoNCiAgICA8IS0tIFdHIG5hbWUg YXQgdGhlIHVwcGVybGVmdCBjb3JuZXIgb2YgdGhlIGRvYywNCiAgICAgICAgIElFVEYgaXMgZmlu ZSBmb3IgaW5kaXZpZHVhbCBzdWJtaXNzaW9ucy4gIA0KICAgSWYgdGhpcyBlbGVtZW50IGlzIG5v dCBwcmVzZW50LCB0aGUgZGVmYXVsdCBpcyAiTmV0d29yayBXb3JraW5nIEdyb3VwIiwNCiAgICAg ICAgIHdoaWNoIGlzIHVzZWQgYnkgdGhlIFJGQyBFZGl0b3IgYXMgYSBub2QgdG8gdGhlIGhpc3Rv cnkgb2YgdGhlIElFVEYuIC0tPg0KDQogICAgPGtleXdvcmQ+Q0JPUjwva2V5d29yZD4NCiAgICA8 a2V5d29yZD5ZQU5HPC9rZXl3b3JkPg0KICAgIDxrZXl3b3JkPkVuY29kaW5nPC9rZXl3b3JkPg0K DQogICAgPCEtLSBLZXl3b3JkcyB3aWxsIGJlIGluY29ycG9yYXRlZCBpbnRvIEhUTUwgb3V0cHV0 DQogICAgICAgICBmaWxlcyBpbiBhIG1ldGEgdGFnIGJ1dCB0aGV5IGhhdmUgbm8gZWZmZWN0IG9u IHRleHQgb3IgbnJvZmYNCiAgICAgICAgIG91dHB1dC4gSWYgeW91IHN1Ym1pdCB5b3VyIGRyYWZ0 IHRvIHRoZSBSRkMgRWRpdG9yLCB0aGUNCiAgICAgICAgIGtleXdvcmRzIHdpbGwgYmUgdXNlZCBm b3IgdGhlIHNlYXJjaCBlbmdpbmUuIC0tPg0KDQogICAgPGFic3RyYWN0Pg0KICAgICAgPHQ+VGhp cyBkb2N1bWVudCBkZWZpbmVzIGVuY29kaW5nIHJ1bGVzIGZvciByZXByZXNlbnRpbmcgY29uZmln dXJhdGlvbiwgc3RhdGUgZGF0YSwgUlBDIGlucHV0IGFuZCBvdXRwdXQgcGFyYW1ldGVycywgYW5k IG5vdGlmaWNhdGlvbnMgZGVmaW5lZCB1c2luZyBZQU5HIGFzIENvbmNpc2UgQmluYXJ5IE9iamVj dCBSZXByZXNlbnRhdGlvbiAoQ0JPUikgPHhyZWYgdGFyZ2V0PSJSRkM3MDQ5IiAvPi48L3Q+DQog ICAgPC9hYnN0cmFjdD4NCiAgPC9mcm9udD4NCg0KICA8bWlkZGxlPg0KICANCjwhLS0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0tPg0KPHNlY3Rpb24gdGl0bGU9IkludHJvZHVjdGlvbiI+DQoN Cjx0PlRPIERPLjwvdD4NCg0KICA8c2VjdGlvbiB0aXRsZT0iVGVybWlub2xvZ3kiPg0KICANCiAg PHQ+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs ICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMjExOSIgLz4uPC90Pg0KICAgIA0KICA8 dD5UaGlzIHNwZWNpZmljYXRpb24gbWFrZXMgdXNlIG9mIHRoZSBmb2xsb3dpbmcgdGVybWlub2xv Z3k6DQogICAgPGxpc3Qgc3R5bGU9InN5bWJvbHMiPg0KICAgICAgPHQ+RGF0YSBub2RlOiBBIG5v ZGUgaW4gdGhlIFlBTkcgc2NoZW1hIHRoYXQgY2FuIGJlIGluc3RhbnRpYXRlZCBpbiBhIERhdGFz dG9yZS4gT25lIG9mIGNvbnRhaW5lciwgbGVhZiwgbGVhZi1saXN0LCBsaXN0LCBvciBhbnl4bWwu PC90Pg0KICAgICAgPHQ+Q2hpbGQgZGF0YSBub2RlOiBBIGRhdGEgbm9kZSBkZWZpbmVkIHdpdGhp biBhIGNvbnRhaW5lciBvciBhIGxpc3QgaXMgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5lciBvciBs aXN0LiBUaGUgY29udGFpbmVyIG9yIGxpc3QgaXMgdGhlIHBhcmVudCBvZiB0aGUgZGF0YSBub2Rl LjwvdD4NCiAgICAgIDx0PklkZW50aWZpZXI6IEFuIGlkZW50aWZpZXIgZW1ib2RpZXMgdGhlIGlu Zm9ybWF0aW9uIHJlcXVpcmVkIHRvIGRpc3Rpbmd1aXNoIHdoYXQgaXMgYmVpbmcgaWRlbnRpZmll ZCBmcm9tIGFsbCBvdGhlciB0aGluZ3Mgd2l0aGluIGl0cyBzY29wZSBvZiBpZGVudGlmaWNhdGlv bi48L3Q+DQogICAgICA8dD5QYXJlbnQgZGF0YSBub2RlOiBTZWUgQ2hpbGQgZGF0YSBub2RlLjwv dD4NCiAgICA8L2xpc3Q+DQogIDwvdD4NCiAgPC9zZWN0aW9uPg0KICA8IS0tIEVORCAtIFRlcm1p bm9sb2d5IC0tPg0KICANCjwvc2VjdGlvbj4NCjwhLS0gRU5EIC0gSW50cm9kdWN0aW9uIC0tPg0K DQo8IS0tIFNUQVJUIC0gVGV4dHVhbCByZXByZXNlbnRhdGlvbiBvZiBDQk9SIGNvbnRlbnRzIC0t Pg0KPHNlY3Rpb24gdGl0bGU9IlRleHR1YWwgcmVwcmVzZW50YXRpb24gb2YgQ0JPUiBjb250ZW50 cyI+DQogIDx0PkNvT0wgZW5jb2RlcyBwYXlsb2FkcyBhbmQgdGhlICJGaWVsZHMiIENvQVAgb3B0 aW9uIHVzaW5nIHRoZSBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IGFzIGRlZmluZWQgYnkgPHhyZWYgdGFyZ2V0PSJSRkM3MDQ5IiAvPi4gV2l0aGluIHRoaXMgZG9j dW1lbnQsIHRoaXMgYmluYXJ5IGVuY29kaW5nIGlzIHJlcHJlc2VudGVkIHVzaW5nIGFuIGVxdWl2 YWxlbnQgdGV4dHVhbCBmb3JtLiBUaGlzIHRleHR1YWwgZm9ybSBpcyB1c2VkIHN0cmljdGx5IGZv ciBkb2N1bWVudGF0aW9uIHB1cnBvc2VzIGFuZCBpcyBuZXZlciB0cmFuc21pdHRlZCBhcyBzdWNo LjwvdD4NCiAgDQogIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgIDxwcmVhbWJsZT5UaGUgZm9s bG93aW5nIHRhYmxlIHN1bW1hcml6ZXMgdGhpcyByZXByZXNlbnRhdGlvbi4gVG8gZmFjaWxpdGF0 ZSBpdHMgdW5kZXJzdGFuZGluZywgdGhpcyByZXByZXNlbnRhdGlvbiBmb2xsb3dzIHRoZSBKU09O IHN5bnRheCAod2hlbiBwb3NzaWJsZSkgPHhyZWYgdGFyZ2V0PSJSRkM3MTU5IiAvPi48L3ByZWFt YmxlPg0KDQogICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KKy0tLS0tLS0tLS0r LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0r DQp8IENCT1IgICAgIHwgQ0JPUiB8IFRleHQgcmVwcmVzZW50YXRpb24gICAgICB8IEV4YW1wbGUg ICB8IENCT1IgICAgIHwNCnwgY29udGVudCAgfCB0eXBlIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgIHwgZW5jb2RpbmcgfA0KKy0tLS0tLS0tLS0rLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQp8IFVuc2lnbmVkIHwg MCAgICB8IERlY2ltYWwgZGlnaXRzICAgICAgICAgICB8IDEyMyAgICAgICB8IDE4IDdiICAgIHwN CnwgaW50ZWdlciAgfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwgICAgICAgICAgfA0KfCAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgfCAgICAgICAgICB8DQp8IE5lZ2F0aXZlIHwgMSAgICB8IERlY2ltYWwg ZGlnaXRzIHByZWZpeGVkICB8IC0xMjMgICAgICB8IDM4IDdhICAgIHwNCnwgaW50ZWdlciAgfCAg ICAgIHwgYnkgYSBtaW51cyBzaWduLiAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfA0K fCAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICB8DQp8IEJ5dGUgICAgIHwgMiAgICB8IEhleGFkZWNpbWFsIHZhbHVlICAgICAg ICB8IGgnIGYxNWMnICB8IDQyIGYxNWMgIHwNCnwgc3RyaW5nICAgfCAgICAgIHwgZW5jbG9zZWQg YmV0d2VlbiBzaW5nbGUgIHwgICAgICAgICAgIHwgICAgICAgICAgfA0KfCAgICAgICAgICB8ICAg ICAgfCBxdW90ZXMgYW5kIHByZWZpeGVkIGJ5ICAgfCAgICAgICAgICAgfCAgICAgICAgICB8DQp8 ICAgICAgICAgIHwgICAgICB8IGFuICdoJy4gICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgIHwNCnwgICAgICAgICAgfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgIHwgICAgICAgICAgfA0KfCBUZXh0ICAgICB8IDMgICAgfCBTdHJpbmcgb2Yg VW5pY29kZSAgICAgICAgfCAidHh0IiAgICAgfCA2MyAgICAgICB8DQp8IHN0cmluZyAgIHwgICAg ICB8IGNoYXJhY3RlcnMgZW5jbG9zZWQgICAgICB8ICAgICAgICAgICB8IDc0Nzg3NCAgIHwNCnwg ICAgICAgICAgfCAgICAgIHwgYmV0d2VlbiBkb3VibGUgcXVvdGVzICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgfA0KfCAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgfCAgICAgICAgICB8DQp8IEFycmF5ICAgIHwgNCAgICB8IENvbW1hIHNlcGFy YXRlZCBsaXN0ICAgICB8IFsgMSwgMiBdICB8IDgyIDAxIDAyIHwNCnwgICAgICAgICAgfCAgICAg IHwgb2YgdmFsdWVzIHdpdGhpbiAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfA0KfCAg ICAgICAgICB8ICAgICAgfCBzcXVhcmUgYnJhY2tldHMuICAgICAgICAgfCAgICAgICAgICAgfCAg ICAgICAgICB8DQp8ICAgICAgICAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8ICAgICAgICAgIHwNCnwgTWFwICAgICAgfCA1ICAgIHwgQ29tbWEgc2VwYXJh dGVkIGxpc3QgICAgIHwgeyAgICAgICAgIHwgYTIgICAgICAgfA0KfCAgICAgICAgICB8ICAgICAg fCBvZiBuYW1lL3ZhbHVlIHBhaXIgICAgICAgfCAgIDE6IDEyMywgfCAgMDExODdiICB8DQp8ICAg ICAgICAgIHwgICAgICB8IHdpdGhpbiBjdXJseSBicmFjZXMuICAgICB8ICAgMjogNDU2ICB8ICAw MjE5MDFjOHwNCnwgICAgICAgICAgfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwg fSAgICAgICAgIHwgICAgICAgICAgfA0KfCAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICB8DQp8IEJvb2xlYW4gIHwgNy8yMCB8 IGZhbHNlICAgICAgICAgICAgICAgICAgICB8IGZhbHNlICAgICB8IGY0ICAgICAgIHwNCnwgICAg ICAgICAgfCA3LzIxIHwgdHJ1ZSAgICAgICAgICAgICAgICAgICAgIHwgdHJ1ZSAgICAgIHwgZjUg ICAgICAgfA0KfCAgICAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgfCAgICAgICAgICB8DQp8IE51bGwgICAgIHwgNy8yMiB8IG51bGwgICAgICAgICAg ICAgICAgICAgICB8IG51bGwgICAgICB8IGY2ICAgICAgIHwNCnwgICAgICAgICAgfCAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgfA0KfCBOb3Qg ICAgICB8IDcvMjMgfCB1bmRlZmluZWQgICAgICAgICAgICAgICAgfCB1bmRlZmluZWQgfCBmNyAg ICAgICB8DQp8IGFzc2lnbmVkIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICB8ICAgICAgICAgIHwNCistLS0tLS0tLS0tKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tKw0KICAgIF1dPjwvYXJ0d29yaz4NCiAg PC9maWd1cmU+DQo8L3NlY3Rpb24+DQo8IS0tIEVORCAtIFRleHR1YWwgcmVwcmVzZW50YXRpb24g b2YgQ0JPUiBjb250ZW50cyAtLT4NCg0KDQo8IS0tIFNUQVJUIC0gWUFORyB0byBDQk9SIG1hcHBp bmcgLS0+DQo8c2VjdGlvbiBhbmNob3I9InlhbmdfY2Jvcl9tYXBwaW5nIiB0aXRsZT0iWUFORyB0 byBDQk9SIG1hcHBpbmciPg0KDQo8dD5PYmplY3RzIGRlZmluZWQgdXNpbmcgdGhlIFlBTkcgbW9k ZWxpbmcgbGFuZ3VhZ2UgYXJlIGVuY29kZWQgdXNpbmcgQ0JPUiA8eHJlZiB0YXJnZXQ9IlJGQzcw NDkiIC8+IGJhc2VkIG9uIHRoZSBydWxlcyBkZWZpbmVkIGluIHRoaXMgc2VjdGlvbi4gV2UgYXNz dW1lIHRoYXQgdGhlIHJlYWRlciBpcyBhbHJlYWR5IGZhbWlsaWFyIHdpdGggYm90aCBZQU5HIDx4 cmVmIHRhcmdldD0iUkZDNjAyMCIgLz4gYW5kIENCT1IgPHhyZWYgdGFyZ2V0PSJSRkM3MDQ5IiAv Pi48L3Q+DQoNCiAgPHNlY3Rpb24gdGl0bGU9IllBTkcgbGVhZiI+DQogIDx0PlRoZSBsZWFmIHN0 YXRlbWVudCBkZWZpbmVzIGEgZGF0YSBub2RlIGFzc29jaWF0ZWQgd2l0aCBhIHZhbHVlLiBUaGUg Zm9sbG93aW5nIHN1YnNlY3Rpb25zIGRlc2NyaWJlIHRoZSBlbmNvZGluZyBvZiBkaWZmZXJlbnQg bGVhZiB0eXBlcy48L3Q+DQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBiaW5hcnki Pg0KICAgIDx0PkxlYWZzIG9mIHR5cGUgYmluYXJ5IE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENC T1IgYnl0ZSBzdHJpbmcgZGF0YSBpdGVtIChtYWpvciB0eXBlIDApLjwvdD4NCiAgDQogICAgPGZp Z3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+RGVmaW5pdGlvbiBleGFtcGxlOjwv cHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIGFl czEyOC1rZXkgew0KICB0eXBlIGJpbmFyeSB7DQogICAgbGVuZ3RoIDE2Ow0KICB9DQp9DQogICAg ICBdXT48L2FydHdvcms+DQogICAgPC9maWd1cmU+DQogICAgPHQ+VGV4dHVhbCBmb3JtOiBoJzFm MWNlNmEzZjQyNjYwZDg4OGQ5MmE0ZDgwMzA0NzZlJzwvdD4NCiAgICA8dD5DQk9SIGVuY29kaW5n OiA1MCAxZjFjZTZhM2Y0MjY2MGQ4ODhkOTJhNGQ4MDMwNDc2ZTwvdD4NCiAgICA8L3NlY3Rpb24+ IA0KICAgIA0KDQogICAgPHNlY3Rpb24gdGl0bGU9IllBTkcgdHlwZTogYml0cyI+DQogICAgPHQ+ TGVhZnMgb2YgdHlwZSBiaXRzIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgYnl0ZSBzdHJp bmcgZGF0YSBpdGVtIChtYWpvciB0eXBlIDApLiBCaXRzIHBvc2l0aW9uIDAgdG8gNyBhcmUgYXNz aWduZWQgdG8gdGhlIGZpcnN0IGJ5dGUgd2l0aGluIHRoZSBieXRlIHN0cmluZywgYml0cyA4IHRv IDE1IHRvIHRoZSBzZWNvbmQgYnl0ZSwgYW5kIHN1YnNlcXVlbnQgYnl0ZXMgYXJlIGFzc2lnbmVk IHNpbWlsYXJseS4gV2l0aGluIGVhY2ggYnl0ZSwgYml0cyBhcmUgYXNzaWduZWQgZnJvbSBsZWFz dCB0byBtb3N0IHNpZ25pZmljYW50LjwvdD4NCiAgDQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+ DQogICAgICA8cHJlYW1ibGU+RGVmaW5pdGlvbiBleGFtcGxlIDx4cmVmIHRhcmdldD0iUkZDNjAy MCIgLz46PC9wcmVhbWJsZT4NCiAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48IVtDREFUQVsN CmxlYWYgbXliaXRzIHsNCiAgdHlwZSBiaXRzIHsNCiAgICBiaXQgZGlzYWJsZS1uYWdsZSB7DQog ICAgICBwb3NpdGlvbiAwOw0KICAgIH0NCiAgICBiaXQgYXV0by1zZW5zZS1zcGVlZCB7DQogICAg ICBwb3NpdGlvbiAxOw0KICAgIH0NCiAgICBiaXQgMTAtTWItb25seSB7DQogICAgICBwb3NpdGlv biAyOw0KICAgIH0NCiAgfQ0KfQ0KICAgICAgXV0+PC9hcnR3b3JrPg0KICAgIDwvZmlndXJlPg0K ICAgIDx0PlRleHR1YWwgZm9ybTogaCcwNScgKFJlcHJlc2VudHMgYml0cyBkaXNhYmxlLW5hZ2xl IGFuZCAxMC1NYi1vbmx5IHNldCk8L3Q+DQogICAgPHQ+Q0JPUiBlbmNvZGluZzogNDEgMDU8L3Q+ DQogICAgPC9zZWN0aW9uPg0KICAgIA0KICAgIA0KICAgIDxzZWN0aW9uIHRpdGxlPSJZQU5HIHR5 cGU6IGJvb2xlYW4gIj4NCiAgICA8dD5MZWFmcyBvZiB0eXBlIGJvb2xlYW4gTVVTVCBiZSBlbmNv ZGVkIHVzaW5nIGEgQ0JPUiB0cnVlIChtYWpvciB0eXBlIDcsIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gMjEpIG9yIGZhbHNlIGRhdGEgaXRlbSAobWFqb3IgdHlwZSA3LCBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIDIwKS48L3Q+DQogIA0KICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHBy ZWFtYmxlPkRlZmluaXRpb24gZXhhbXBsZSA8eHJlZiB0YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJl YW1ibGU+DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIGVuYWJs ZWQgew0KICB0eXBlIGJvb2xlYW47DQp9DQogICAgICBdXT48L2FydHdvcms+DQogICAgPC9maWd1 cmU+DQogICAgPHQ+VGV4dHVhbCBmb3JtOiB0cnVlPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6 IGY1PC90Pg0KICAgIDwvc2VjdGlvbj4NCg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IllBTkcgdHlw ZTogZGVjaW1hbDY0ICI+DQogICAgPHQ+TGVhZnMgb2YgdHlwZSBkZWNpbWFsNjQgTVVTVCBiZSBl bmNvZGVkIHVzaW5nIGEgQ0JPUiB1bnNpZ25lZCBpbnRlZ2VyIGRhdGEgaXRlbSAobWFqb3IgdHlw ZSAwKS48L3Q+DQogIA0KICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxl PkRlZmluaXRpb24gZXhhbXBsZSA8eHJlZiB0YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJlYW1ibGU+ DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIG15LWRlY2ltYWwg ew0KICB0eXBlIGRlY2ltYWw2NCB7DQogICAgZnJhY3Rpb24tZGlnaXRzIDI7DQogICAgcmFuZ2Ug IjEgLi4gMy4xNCB8IDEwIHwgMjAuLm1heCI7DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4N CiAgICA8L2ZpZ3VyZT4NCiAgICA8dD5UZXh0dWFsIGZvcm06IDI1NyAoUmVwcmVzZW50cyBkZWNp bWFsIHZhbHVlIDIuNTcpPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6IDE5IDAxMDE8L3Q+DQog ICAgPC9zZWN0aW9uPg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IllBTkcgdHlwZTogZW1wdHkgIj4N CiAgICA8dD5MZWFmcyBvZiB0eXBlIGVtcHR5IE1VU1QgYmUgZW5jb2RlZCB1c2luZyB0aGUgQ0JP UiBudWxsIHZhbHVlIChtYWpvciB0eXBlIDcsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gMjIpLjwv dD4NCiAgDQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+RGVmaW5p dGlvbiBleGFtcGxlIDx4cmVmIHRhcmdldD0iUkZDNzI3NyIgLz46PC9wcmVhbWJsZT4NCiAgICAg IDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48IVtDREFUQVsNCmxlYWYgaXMtcm91dGVyIHsNCiAgdHlw ZSBlbXB0eTsNCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4gICAgDQogICAgPC9maWd1cmU+DQogICAg PHQ+VGV4dHVhbCBmb3JtOiBudWxsPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6IGY2PC90Pg0K ICA8L3NlY3Rpb24+DQoNCg0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBlbnVtZXJhdGlv biAiPg0KICAgIDx0PkxlYWZzIG9mIHR5cGUgZW51bWVyYXRpb24gTVVTVCBiZSBlbmNvZGVkIHVz aW5nIGEgQ0JPUiB1bnNpZ25lZCBpbnRlZ2VyIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAwKS48L3Q+ DQogIA0KICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRlZmluaXRp b24gZXhhbXBsZSA8eHJlZiB0YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJlYW1ibGU+DQogICAgICA8 YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIG9wZXItc3RhdHVzIHsNCiAgdHlw ZSBlbnVtZXJhdGlvbiB7DQogICAgZW51bSB1cCB7IHZhbHVlIDE7IH0NCiAgICBlbnVtIGRvd24g eyB2YWx1ZSAyOyB9DQogICAgZW51bSB0ZXN0aW5nIHsgdmFsdWUgMzsgfQ0KICAgIGVudW0gdW5r bm93biB7IHZhbHVlIDQ7IH0NCiAgICBlbnVtIGRvcm1hbnQgeyB2YWx1ZSA1OyB9DQogICAgZW51 bSBub3QtcHJlc2VudCB7IHZhbHVlIDY7IH0NCiAgICBlbnVtIGxvd2VyLWxheWVyLWRvd24geyB2 YWx1ZSA3OyB9DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4gICAgICANCiAgICA8L2ZpZ3Vy ZT4NCiAgICA8dD5UZXh0dWFsIGZvcm06IDMgKFJlcHJlc2VudHMgZW51bWVyYXRpb24gdmFsdWUg InRlc3RpbmciKTwvdD4NCiAgICA8dD5DQk9SIGVuY29kaW5nOiAwMzwvdD4NCiAgPC9zZWN0aW9u Pg0KDQoNCiAgPHNlY3Rpb24gdGl0bGU9IllBTkcgdHlwZTogaWRlbnRpdHlyZWYgIj4NCiAgICA8 dD5MZWFmcyBvZiB0eXBlIGlkZW50aXR5cmVmIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1Ig dGV4dCBzdHJpbmcgZGF0YSBpdGVtIChtYWpvciB0eXBlIDMpLiBVbmxpa2UgWE1MLCBDQk9SIGRv ZXMgbm90IHN1cHBvcnQgbmFtZXNwYWNlcy4gVG8gb3ZlcmNvbWUgdGhpcyBsaW1pdGF0aW9uLCBp ZGVudGl0aWVzIGFyZSBlbmNvZGVkIHVzaW5nIGEgY29uY2F0ZW5hdGlvbiBvZiB0aGUgaWRlbnRp dHkgbmFtZShzKSBvZiB0aGUgcmVmZXJlbmNlZCBpZGVudGl0aWVzLCBleGNsdWRpbmcgdGhlIGJh c2UgaWRlbnRpdHkgYW5kIHNlcGFyYXRlZCBieSBkb3QocykuPC90Pg0KICANCiAgICA8ZmlndXJl IGFsaWduPSJsZWZ0Ij4NCiAgICAgIDxwcmVhbWJsZT5EZWZpbml0aW9uIGV4YW1wbGUgPHhyZWYg dGFyZ2V0PSJSRkM3MjIzIiAvPjo8L3ByZWFtYmxlPg0KICAgICAgPGFydHdvcmsgYWxpZ249Imxl ZnQiPjwhW0NEQVRBWw0KaWRlbnRpdHkgaW50ZXJmYWNlLXR5cGUgew0KfQ0KDQppZGVudGl0eSBp YW5hLWludGVyZmFjZS10eXBlIHsNCiAgYmFzZSBpbnRlcmZhY2UtdHlwZTsNCn0NCg0KaWRlbnRp dHkgZXRoZXJuZXRDc21hY2Qgew0KICBiYXNlIGlhbmEtaW50ZXJmYWNlLXR5cGU7DQp9DQoNCmxl YWYgdHlwZSB7DQogIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgIGJhc2UgaW50ZXJmYWNlLXR5cGU7 DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4gICAgIA0KICAgIDwvZmlndXJlPg0KICAgIDx0 PlRleHR1YWwgZm9ybTogImlhbmEtaW50ZXJmYWNlLXR5cGUuZXRoZXJuZXRDc21hY2QiPC90Pg0K ICAgIDx0PkNCT1IgZW5jb2Rpbmc6IDc4IDIyIDY5NjE2ZTYxMmQ2OTZlNzQ2NTcyNjY2MTYzNjUy ZDc0Nzk3MDY1MmU2NTc0Njg2NTcyNmU2NTc0NDM3MzZkNjE2MzY0PC90Pg0KICAgIDwvc2VjdGlv bj4NCg0KDQogICAgPHNlY3Rpb24gdGl0bGU9IllBTkcgdHlwZTogaW5zdGFuY2UtaWRlbnRpZmll ciI+DQogICAgPHQ+V2hlbiBhIGxlYWYgbm9kZSBvZiB0eXBlIGluc3RhbmNlLWlkZW50aWZpZXIg aWRlbnRpZmllcyBhIHNpbmdsZSBpbnN0YW5jZSBkYXRhIG5vZGUgKGRhdGEgbm9kZSBub3QgcGFy dCBvZiBhIGxpc3QpLCBpdHMgdmFsdWUgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIGEgQ0JPUiB1bnNp Z25lZCBpbnRlZ2VyIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAwKSBjb250YWluaW5nIHRoZSB0YXJn ZXRlZCBkYXRhIG5vZGUgSUQuPC90Pg0KICANCiAgICA8ZmlndXJlIGFsaWduPSJsZWZ0Ij4NCiAg ICAgIDxwcmVhbWJsZT5EZWZpbml0aW9uIGV4YW1wbGUgPHhyZWYgdGFyZ2V0PSJSRkM3MzE3IiAv Pjo8L3ByZWFtYmxlPg0KICAgICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KY29u dGFpbmVyIHN5c3RlbSB7DQoNCiAgbGVhZiBjb250YWN0IHsNCiAgICB0eXBlIHN0cmluZzsNCiAg fQ0KDQogIGxlYWYgaG9zdG5hbWUgew0KICAgIHR5cGUgaW5ldDpkb21haW4tbmFtZTsNCiAgfQ0K fQ0KICAgICAgXV0+PC9hcnR3b3JrPg0KICAgIDwvZmlndXJlPg0KICAgIDx0PlRleHR1YWwgZm9y bTogNjk2MzU8L3Q+DQogICAgPHQ+Q0JPUiBlbmNvZGluZzogMWEgMDAwMTEwMDM8L3Q+DQogICAg PHQ+SW4gdGhpcyBleGFtcGxlLCB0aGUgdmFsdWUgNjk2MzUgaWRlbnRpZmllcyB0aGUgaW5zdGFu Y2Ugb2YgdGhlIGRhdGEgbm9kZSAiaG9zdG5hbWUiIHdpdGhpbiB0aGUgaWV0Zi1zeXN0ZW0gbW9k dWxlLiBBc3N1bWluZyBtb2R1bGUgSUQgPSA2OCBhbmQgZGF0YSBub2RlIElEID0gMy48L3Q+DQoN CiAgICA8dD5XaGVuIGEgbGVhZiBub2RlIG9mIHR5cGUgaW5zdGFuY2UtaWRlbnRpZmllciBpZGVu dGlmaWVzIGEgZGF0YSBub2RlIHN1cHBvcnRpbmcgbXVsdGlwbGUgaW5zdGFuY2VzIChkYXRhIG5v ZGUgcGFydCBvZiBhIGxpc3QpLCBpdHMgdmFsdWUgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIGEgQ0JP UiBhcnJheSBkYXRhIGl0ZW0gKG1ham9yIHR5cGUgNCkgY29udGFpbmluZyB0aGUgZm9sbG93aW5n IGVudHJpZXM6DQogICAgICANCiAgICAgIDxsaXN0ICBzdHlsZT0ic3ltYm9scyI+DQogICAgICAg IDx0PmEgQ0JPUiB1bnNpZ25lZCBpbnRlZ2VyIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAwKSBjb250 YWluaW5nIHRoZSBmdWxseS1xdWFsaWZpZWQgZGF0YSBub2RlIElEIG9mIHRoZSB0YXJnZXRlZCBk YXRhIG5vZGUuPC90Pg0KICAgICAgICA8dD5hIENCT1IgYXJyYXkgZGF0YSBpdGVtIChtYWpvciB0 eXBlIDQpIGNvbnRhaW5pbmcgdGhlIHZhbHVlIG9mIGVhY2gga2V5IHJlcXVpcmVkIHRvIGlkZW50 aWZ5IHRoZSBpbnN0YW5jZSBvZiB0aGUgdGFyZ2V0ZWQgZGF0YSBub2RlLiBUaGVzZSBrZXlzIE1V U1QgYmUgb3JkZXJlZCBhcyBkZWZpbmVkIGluIHRoZSAia2V5IiBZQU5HIHN0YXRlbWVudCwgc3Rh cnRpbmcgZnJvbSB0b3AgbGV2ZWwgbGlzdCwgYW5kIGZvbGxvdyBieSBlYWNoIG9mIHRoZSBzdWJv cmRpbmF0ZSBsaXN0KHMpLjwvdD4NCiAgICAgIDwvbGlzdD4NCiAgICA8L3Q+DQogICAgDQogICAg PGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+RGVmaW5pdGlvbiBleGFtcGxl IDx4cmVmIHRhcmdldD0iUkZDNzMxNyIgLz46PC9wcmVhbWJsZT4NCiAgICAgIDxhcnR3b3JrIGFs aWduPSJsZWZ0Ij48IVtDREFUQVsNCmxpc3QgdXNlciB7DQogIGtleSBuYW1lOw0KDQogIGxlYWYg bmFtZSB7DQogICAgdHlwZSBzdHJpbmc7DQogIH0NCiAgbGVhZiBwYXNzd29yZCB7DQogICAgdHlw ZSBpYW5hY2g6Y3J5cHQtaGFzaDsNCiAgfQ0KICANCiAgbGlzdCBhdXRob3JpemVkLWtleSB7DQog ICAga2V5IG5hbWU7DQoNCiAgICBsZWFmIG5hbWUgew0KICAgICAgdHlwZSBzdHJpbmc7DQogICAg fQ0KICAgIGxlYWYgYWxnb3JpdGhtIHsNCiAgICAgIHR5cGUgc3RyaW5nOw0KICAgIH0NCiAgICBs ZWFmIGtleS1kYXRhIHsNCiAgICAgIHR5cGUgYmluYXJ5Ow0KICB9DQp9DQogICAgICBdXT48L2Fy dHdvcms+DQogICAgPC9maWd1cmU+DQogICAgPHQ+VGV4dHVhbCBmb3JtOiBbNjk2NzksIFsiYm9i IiwgImFkbWluIl1dPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6IDgyICAxYSAwMDAxMTAyZiAg ODIgIDYzIDYyNmY2MiAgNjUgNjE2NDZkNjk2ZTwvdD4NCiAgICA8dD5UaGlzIGV4YW1wbGUgaWRl bnRpZmllcyB0aGUgaW5zdGFuY2Ugb2YgdGhlIGRhdGEgbm9kZSAia2V5LWRhdGEiIHdpdGhpbiB0 aGUgaWV0Zi1zeXN0ZW0gbW9kdWxlLCBhc3NvY2lhdGVkIHdpdGggdXNlciBuYW1lICJib2IiIGFu ZCBhdXRob3JpemVkLWtleSBuYW1lICJhZG1pbiIuIEFzc3VtaW5nIG1vZHVsZSBJRCA9IDY4IGFu ZCBkYXRhIG5vZGUgSUQgPSA0Ny48L3Q+DQogIDwvc2VjdGlvbj4NCg0KDQogIDxzZWN0aW9uIHRp dGxlPSJZQU5HIHR5cGU6IGludDgsIGludDE2LCBpbnQzMiwgaW50NjQgIj4NCiAgICA8dD5MZWFm cyBvZiB0eXBlIGludDgsIGludDE2LCBpbnQzMiBhbmQgaW50NjQgTVVTVCBiZSBlbmNvZGVkIHVz aW5nIGVpdGhlciBDQk9SIHVuc2lnbmVkIGludGVnZXIgKG1ham9yIHR5cGUgMCkgb3IgQ0JPUiBz aWduZWQgaW50ZWdlciAobWFqb3IgdHlwZSAwKSwgZGVwZW5kaW5nIG9uIHRoZSBhY3R1YWwgdmFs dWUuPC90Pg0KICANCiAgICA8ZmlndXJlIGFsaWduPSJsZWZ0Ij4NCiAgICAgIDxwcmVhbWJsZT5E ZWZpbml0aW9uIGV4YW1wbGUgPHhyZWYgdGFyZ2V0PSJSRkM3MzE3IiAvPjo8L3ByZWFtYmxlPg0K ICAgICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KbGVhZiB0aW1lem9uZS11dGMt b2Zmc2V0IHsNCiAgdHlwZSBpbnQxNiB7DQogICAgcmFuZ2UgIi0xNTAwIC4uIDE1MDAiOw0KICB9 DQp9DQogICAgXV0+PC9hcnR3b3JrPiAgICAgDQogICAgPC9maWd1cmU+DQogICAgPHQ+VGV4dHVh bCBmb3JtOiAtMzAwPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6IDM5IDAxMmI8L3Q+DQogIDwv c2VjdGlvbj4NCg0KDQogIDxzZWN0aW9uIHRpdGxlPSJZQU5HIHR5cGU6IGxlYWZyZWYgIj4NCiAg ICA8dD5MZWFmcyBvZiB0eXBlIGxlYWZyZWYgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIHRoZSBydWxl cyBvZiB0aGUgZGF0YSBub2RlIHJlZmVyZW5jZWQgYnkgdGhlICJwYXRoIiBZQU5HIHN0YXRlbWVu dC48L3Q+DQogIA0KICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRl ZmluaXRpb24gZXhhbXBsZSA8eHJlZiB0YXJnZXQ9IlJGQzcyMjMiIC8+OjwvcHJlYW1ibGU+DQog ICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQp0eXBlZGVmIGludGVyZmFjZS1z dGF0ZS1yZWYgew0KICB0eXBlIGxlYWZyZWYgew0KICAgIHBhdGggIi9pbnRlcmZhY2VzLXN0YXRl L2ludGVyZmFjZS9uYW1lIjsNCiAgfQ0KfQ0KDQpjb250YWluZXIgaW50ZXJmYWNlcy1zdGF0ZSB7 DQogIGxpc3QgaW50ZXJmYWNlIHsNCiAgICBrZXkgIm5hbWUiOw0KICAgIGxlYWYgbmFtZSB7DQog ICAgICB0eXBlIHN0cmluZzsNCiAgICB9DQogICAgbGVhZi1saXN0IGhpZ2hlci1sYXllci1pZiB7 DQogICAgICB0eXBlIGludGVyZmFjZS1zdGF0ZS1yZWY7DQogICAgfQ0KICB9DQp9DQogICAgICBd XT48L2FydHdvcms+ICAgICAgDQogICAgPC9maWd1cmU+DQogICAgPHQ+VGV4dHVhbCBmb3JtOiAi ZXRoMS4xMCI8L3Q+DQogICAgPHQ+Q0JPUiBlbmNvZGluZzogNjcgNjU3NDY4MzEyZTMxMzA8L3Q+ DQogIDwvc2VjdGlvbj4NCiAgICANCg0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBzdHJp bmcgIj4NCiAgICA8dD5MZWFmcyBvZiB0eXBlIHN0cmluZyBNVVNUIGJlIGVuY29kZWQgdXNpbmcg YSBDQk9SIHRleHQgc3RyaW5nIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAzKS48L3Q+DQogIA0KICAg IDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRlZmluaXRpb24gZXhhbXBs ZSA8eHJlZiB0YXJnZXQ9IlJGQzcyMjMiIC8+OjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBh bGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIG5hbWUgew0KICB0eXBlIHN0cmluZzsNCn0NCiAg ICAgICAgXV0+PC9hcnR3b3JrPiAgICAgIA0KICAgICAgPC9maWd1cmU+DQogICAgPHQ+VGV4dHVh bCBmb3JtOiAiZXRoMCI8L3Q+DQogICAgPHQ+Q0JPUiBlbmNvZGluZzogNjQgNjU3NDY4MzA8L3Q+ DQogIDwvc2VjdGlvbj4NCiAgICANCg0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiB1aW50 OCwgdWludDE2LCB1aW50MzIsIHVpbnQ2NCAiPg0KICAgIDx0PkxlYWZzIG9mIHR5cGUgdWludDgs IHVpbnQxNiwgdWludDMyIGFuZCB1aW50NjQgTVVTVCBiZSBlbmNvZGVkIHVzaW5nIGEgQ0JPUiB1 bnNpZ25lZCBpbnRlZ2VyIGRhdGEgaXRlbSAobWFqb3IgdHlwZSAwKS48L3Q+DQogIA0KICAgIDxm aWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRlZmluaXRpb24gZXhhbXBsZSA8 eHJlZiB0YXJnZXQ9IlJGQzcyNzciIC8+OjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBhbGln bj0ibGVmdCI+PCFbQ0RBVEFbDQpsZWFmIG10dSB7DQogIHR5cGUgdWludDE2IHsNCiAgICByYW5n ZSAiNjguLm1heCI7DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4gICAgICANCiAgICA8L2Zp Z3VyZT4NCiAgICA8dD5UZXh0dWFsIGZvcm06IDEyODA8L3Q+DQogICAgPHQ+Q0JPUiBlbmNvZGlu ZzogMTkgMDUwMDwvdD4NCiAgPC9zZWN0aW9uPg0KICAgIA0KDQogIDxzZWN0aW9uIHRpdGxlPSJZ QU5HIHR5cGU6IHVuaW9uICI+DQogICAgPHQ+TGVhZnMgb2YgdHlwZSB1bmlvbiBNVVNUIGJlIGVu Y29kZWQgdXNpbmcgdGhlIHJ1bGVzIGFzc29jaWF0ZWQgd2l0aCBvbmUgb2YgdGhlIHR5cGUgbGlz dGVkLjwvdD4NCiAgDQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+ RGVmaW5pdGlvbiBleGFtcGxlIDx4cmVmIHRhcmdldD0iUkZDNzMxNyIgLz46PC9wcmVhbWJsZT4N CiAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48IVtDREFUQVsNCnR5cGVkZWYgaXB2NC1hZGRy ZXNzIHsNCiAgdHlwZSBzdHJpbmcgew0KICBwYXR0ZXJuICcoKFswLTldfFsxLTldWzAtOV18MVsw LTldWzAtOV18MlswLTRdWzAtOV18MjVbMC01XSlcLil7M30NCiAgICAgICAgICAgKFswLTldWzEt OV1bMC05XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05XXwyNVswLTVdKSglW1xwe059DQogICAgICAg ICAgIFxwe0x9XSspPyc7DQogIH0NCn0NCg0KdHlwZWRlZiBpcHY2LWFkZHJlc3Mgew0KICB0eXBl IHN0cmluZyB7DQogICAgcGF0dGVybiAnKCg6fFswLTlhLWZBLUZdezAsNH0pOikoWzAtOWEtZkEt Rl17MCw0fTopezAsNX0oKChbMC05YQ0KICAgICAgICAgICAgIC1mQS1GXXswLDR9Oik/KDp8WzAt OWEtZkEtRl17MCw0fSkpfCgoKDI1WzAtNV18MlswLTRdWzANCiAgICAgICAgICAgICAtOV18WzAx XT9bMC05XT9bMC05XSlcLil7M30oMjVbMC01XXwyWzAtNF1bMC05XXxbMDFdP1swDQogICAgICAg ICAgICAgLTldP1swLTldKSkpKCVbXHB7Tn1ccHtMfV0rKT8nOw0KICAgIHBhdHRlcm4gJygoW146 XSs6KXs2fSgoW146XSs6W146XSspfCguKlwuLiopKSl8KCgoW146XSs6KSpbXjpdKykNCiAgICAg ICAgICAgICA/OjooKFteOl0rOikqW146XSspPykoJS4rKT8nOw0KICB9DQp9DQoNCnR5cGVkZWYg aXAtYWRkcmVzcyB7DQogIHR5cGUgdW5pb24gew0KICAgIHR5cGUgaXB2NC1hZGRyZXNzOw0KICAg IHR5cGUgaXB2Ni1hZGRyZXNzOw0KICB9DQp9DQoNCmxlYWYgYWRkcmVzcyB7DQogIHR5cGUgaW5l dDppcC1hZGRyZXNzOw0KfQ0KICAgICAgXV0+PC9hcnR3b3JrPg0KICAgIDwvZmlndXJlPg0KICA8 dD5UZXh0dWFsIGZvcm06ICJbMjAwMTpkYjg6MDoxXTo4MCI8L3Q+DQogIDx0PkNCT1IgZW5jb2Rp bmc6IDcxIDViMzIzMDMwMzEzYTY0NjIzODNhMzAzYTMxNWQzYTM4MzA8L3Q+DQogIDwvc2VjdGlv bj4NCiAgICANCg0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBhbnl4bWwgIj4NCiAgICA8 dD5UaGUgImFueXhtbCIgc3RhdGVtZW50IHJlcHJlc2VudHMgYW4gdW5rbm93biBkYXRhIG5vZGUu IFRoZSBlbmNvZGluZyBvZiB0aGlzIGRhdGEgbm9kZSBNVVNUIGZvbGxvdyB0aGUgcnVsZXMgb2Yg b25lIG9mIHRoZSBZQU5HIHN0YXRlbWVudHMgbGlzdGVkIGluIDx4cmVmIHRhcmdldD0ieWFuZ19j Ym9yX21hcHBpbmciIC8+LjwvdD4NCiAgDQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQogICAg ICA8cHJlYW1ibGU+RGVmaW5pdGlvbiBleGFtcGxlIDx4cmVmIHRhcmdldD0iUkZDNjAyMCIgLz46 PC9wcmVhbWJsZT4NCiAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48IVtDREFUQVsNCmFueXht bCBkYXRhOw0KICAgICAgXV0+PC9hcnR3b3JrPiAgICAgIA0KICAgIDwvZmlndXJlPg0KICAgIDx0 PlRleHR1YWwgZm9ybTogMTIzPC90Pg0KICAgIDx0PkNCT1IgZW5jb2Rpbmc6IDE4IDdiPC90Pg0K ICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkFsdGVybmF0ZSB2YWx1 ZTo8L3ByZWFtYmxlPg0KICAgICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0Kew0K ICAxIDogMiwNCiAgMiA6IDU1DQp9DQogICAgICBdXT48L2FydHdvcms+DQogICAgPC9maWd1cmU+ DQogICAgPHQ+Q0JPUiBlbmNvZGluZzogYTIgMDEgMDIgMDIgMTggMzc8L3Q+DQogIDwvc2VjdGlv bj4NCiAgICANCg0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBjb250YWluZXIiPg0KICAg IDx0PkEgY29udGFpbmVyIE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgbWFwIGRhdGEgaXRl bSAobWFqb3IgdHlwZSA1KS4gQSBtYXAgaXMgY29tcHJpc2VkIG9mIHBhaXJzIG9mIGRhdGEgaXRl bXMsIHdpdGggZWFjaCBkYXRhIGl0ZW0gY29uc2lzdGluZyBvZiBhIGtleSBhbmQgYSB2YWx1ZS4N Cg0KQ0JPUiBtYXAga2V5cyBNVVNUIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9SIHVuc2lnbmVkIGlu dGVnZXIgKG1ham9yIHR5cGUgMCkgYW5kIHNldCB0byBhIGRhdGEgbm9kZSBJRCBvciBhIGZ1bGx5 LXF1YWxpZmllZCBkYXRhIG5vZGUgSUQuICBEYXRhIG5vZGUgSURzIE1VU1QgYmUgdXNlZCB3aGVu IGEgcGFyZW50IG5vZGUgZXhpc3RzIGFuZCB0aGlzIHBhcmVudCBzaGFyZXMgdGhlIHNhbWUgbW9k dWxlIElEIGFzIHRoZSBjdXJyZW50IGRhdGEgbm9kZS4NCg0KQ0JPUiBtYXAgdmFsdWVzIE1VU1Qg YmUgZW5jb2RlZCB1c2luZyB0aGUgcnVsZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBkYXRhIG5vZGUg dHlwZS48L3Q+DQogIA0KICAgIDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxl PkRlZmluaXRpb24gZXhhbXBsZSA8eHJlZiB0YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJlYW1ibGU+ DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQp0eXBlZGVmIGRhdGUtYW5k LXRpbWUgew0KICB0eXBlIHN0cmluZyB7DQogICAgcGF0dGVybiAnXGR7NH0tXGR7Mn0tXGR7Mn1U XGR7Mn06XGR7Mn06XGR7Mn0oXC5cZCspPyhafFtcK1wtXQ0KICAgICAgICAgICAgIFxkezJ9Olxk ezJ9KSc7DQogIH0NCn0NCg0KY29udGFpbmVyIGNsb2NrIHsNCiAgbGVhZiBjdXJyZW50LWRhdGV0 aW1lIHsNCiAgICB0eXBlIGRhdGUtYW5kLXRpbWU7DQogIH0NCg0KICBsZWFmIGJvb3QtZGF0ZXRp bWUgew0KICAgICAgICB0eXBlIGRhdGUtYW5kLXRpbWU7DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0 d29yaz4NCiAgICA8L2ZpZ3VyZT4NCiAgICA8ZmlndXJlIGFsaWduPSJsZWZ0Ij4NCiAgICAgIDxw cmVhbWJsZT5UZXh0dWFsIGZvcm06PC9wcmVhbWJsZT4NCiAgICAgIDxhcnR3b3JrIGFsaWduPSJs ZWZ0Ij48IVtDREFUQVsNCnsNCiAgNjk2NjcgOiB7DQogICAgMzYgOiAiMjAxNS0xMC0wMlQxNDo0 NzoyNFotMDU6MDAiLA0KICAgIDM3IDogIjIwMTUtMDktMTVUMDk6MTI6NThaLTA1OjAwIg0KICB9 DQp9DQogICAgICBdXT48L2FydHdvcms+DQogICAgPC9maWd1cmU+DQogICAgPGZpZ3VyZSBhbGln bj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+Q0JPUiBlbmNvZGluZzo8L3ByZWFtYmxlPg0KICAg ICAgPGFydHdvcmsgYWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KYTENCiAgMWEgMDAwMTEwMjMNCiAg YTINCiAgICAxOCAyNCANCiAgICA3OCAxYSAzMjMwMzEzNTJkMzEzMDJkMzAzMjU0MzEzNDNhMzQz NzNhMzIzNDVhMmQzMDM1M2EzMDMwDQogICAgMTggMjUNCiAgICA3OCAxYSAzMjMwMzEzNTJkMzAz OTJkMzEzNTU0MzAzOTNhMzEzMjNhMzUzODVhMmQzMDM1M2EzMDMwDQogICAgICBdXT48L2FydHdv cms+DQogICAgPC9maWd1cmU+DQogICAgPHQ+SW4gdGhpcyBleGFtcGxlLCB3ZSBhc3N1bWUgdGhh dCB0aGUgbW9kdWxlIElEID0gNjgsIGRhdGEgbm9kZSBJRHMgY2xvY2sgPSAzNSwgY3VycmVudC1k YXRldGltZSA9IDM2IGFuZCBib290LWRhdGV0aW1lIDM3LjwvdD4NCiAgICA8L3NlY3Rpb24+DQog ICAgDQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBsZWFmLWxpc3QgIj4NCiAgICA8 dD5BIGxlYWYtbGlzdCBNVVNUIGJlIGVuY29kZWQgdXNpbmcgYSBDQk9SIGFycmF5IGRhdGEgaXRl bSAobWFqb3IgdHlwZSA0KS4gRWFjaCBlbnRyeSBNVVNUIGJlIGVuY29kZWQgdXNpbmcgdGhlIHJ1 bGVzIGRlZmluZWQgYnkgdGhlIHR5cGUgc3BlY2lmaWVkLiA8L3Q+DQogIA0KICAgIDxmaWd1cmUg YWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRlZmluaXRpb24gZXhhbXBsZSA8eHJlZiB0 YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVm dCI+PCFbQ0RBVEFbDQp0eXBlZGVmIGRvbWFpbi1uYW1lIHsNCiAgdHlwZSBzdHJpbmcgew0KICAg IGxlbmd0aCAiMS4uMjUzIjsNCiAgICBwYXR0ZXJuICcoKChbYS16QS1aMC05X10oW2EtekEtWjAt OVwtX10pezAsNjF9KT9bYS16QS1aMC05XS4pDQogICAgICAgICAgICAgKihbYS16QS1aMC05X10o W2EtekEtWjAtOVwtX10pezAsNjF9KT9bYS16QS1aMC05XVwuPw0KICAgICAgICAgICAgICl8XC4n Ow0KICB9DQp9DQoNCmxlYWYtbGlzdCBzZWFyY2ggew0KICB0eXBlIGRvbWFpbi1uYW1lOw0KICBv cmRlcmVkLWJ5IHVzZXI7DQp9DQogICAgICBdXT48L2FydHdvcms+DQogICAgPC9maWd1cmU+DQog ICAgPHQ+VGV4dHVhbCBmb3JtOiBbICJpZXRmLm9yZyIsICJpZWVlLm9yZyIgXTwvdD4NCiAgICA8 dD5DQk9SIGVuY29kaW5nOiA4MiAgNjggNjk2NTc0NjYyZTZmNzI2NyAgNjggNjk2NTY1NjUyZTZm NzI2NzwvdD4NCiAgICA8L3NlY3Rpb24+DQogICAgDQoNCiAgICA8c2VjdGlvbiB0aXRsZT0iWUFO RyB0eXBlOiBsaXN0ICI+DQogICAgPHQ+QSBsaXN0IE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENC T1IgYXJyYXkgZGF0YSBpdGVtIChtYWpvciB0eXBlIDQpLiBFYWNoIGVudHJ5IG9mIHRoaXMgYXJy YXkgaXMgZW5jb2RlZCB1c2luZyBhIENCT1IgbWFwIGRhdGEgaXRlbSAobWFqb3IgdHlwZSA1KSBm b2xsb3dpbmcgdGhlIHNhbWUgcnVsZXMgYXMgYSBZQU5HIGNvbnRhaW5lci48L3Q+DQogIA0KICAg IDxmaWd1cmUgYWxpZ249ImxlZnQiPg0KICAgICAgPHByZWFtYmxlPkRlZmluaXRpb24gZXhhbXBs ZSA8eHJlZiB0YXJnZXQ9IlJGQzczMTciIC8+OjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBh bGlnbj0ibGVmdCI+PCFbQ0RBVEFbDQpsaXN0IHNlcnZlciB7DQogIGtleSBuYW1lOw0KDQogIGxl YWYgbmFtZSB7DQogICAgdHlwZSBzdHJpbmc7DQogIH0NCiAgY2hvaWNlIHRyYW5zcG9ydCB7DQog ICAgY2FzZSB1ZHAgew0KICAgICAgY29udGFpbmVyIHVkcCB7DQogICAgICAgIGxlYWYgYWRkcmVz cyB7DQogICAgICAgICAgdHlwZSBob3N0Ow0KICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAg ICAgICB9DQogICAgICAgIGxlYWYgcG9ydCB7DQogICAgICAgICAgdHlwZSBwb3J0LW51bWJlcjsN CiAgICAgICAgfQ0KICAgICAgfQ0KICAgIH0NCiAgfQ0KICBsZWFmIGFzc29jaWF0aW9uLXR5cGUg ew0KICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgZW51bSBzZXJ2ZXI7DQogICAgICBlbnVt IHBlZXI7DQogICAgICBlbnVtIHBvb2w7DQogICAgfQ0KICAgIGRlZmF1bHQgc2VydmVyOw0KICB9 DQogIGxlYWYgaWJ1cnN0IHsNCiAgICB0eXBlIGJvb2xlYW47DQogICAgZGVmYXVsdCBmYWxzZTsN CiAgfQ0KICBsZWFmIHByZWZlciB7DQogICAgdHlwZSBib29sZWFuOw0KICAgIGRlZmF1bHQgZmFs c2U7DQogIH0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4NCiAgICA8L2ZpZ3VyZT4NCiAgICA8Zmln dXJlIGFsaWduPSJsZWZ0Ij4NCiAgICAgIDxwcmVhbWJsZT5UZXh0dWFsIGZvcm06PC9wcmVhbWJs ZT4NCiAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48IVtDREFUQVsNCnsNCiAgNjk2NDIgOiBb DQogICAgew0KICAgICAgMTE6ICJOUkMgVElDIHNlcnZlciIsDQogICAgICAxMiA6IHsNCiAgICAg ICAgMTM6ICJ0aWMubnJjLmNhIiwNCiAgICAgICAgMTQ6IDEyMw0KICAgICAgfSwNCiAgICAgIDE1 IDogMCwNCiAgICAgIDE2IDogZmFsc2UsDQogICAgICAxNyA6IHRydWUNCiAgICB9LA0KICAgIHsN CiAgICAgIDExOiAiTlJDIFRBQyBzZXJ2ZXIiLA0KICAgICAgMTIgOiB7DQogICAgICAgIDEzOiAi dGFjLm5yYy5jYSINCiAgICAgIH0NCiAgICB9DQogIF0NCn0NCiAgICAgIF1dPjwvYXJ0d29yaz4N CiAgICA8L2ZpZ3VyZT4NCiAgICA8ZmlndXJlIGFsaWduPSJsZWZ0Ij4NCiAgICAgIDxwcmVhbWJs ZT5DQk9SIGVuY29kaW5nOjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVmdCI+ PCFbQ0RBVEFbDQphMQ0KICAgMWEgMDAwMTEwMGENCiAgIDgyDQogICAgICBhNQ0KICAgICAgICAg MGIgNmUgNGU1MjQzMjA1NDQ5NDMyMDczNjU3Mjc2NjU3Mg0KICAgICAgICAgMGMgYTINCiAgICAg ICAgICAgIDBkIDZhIDc0Njk2MzJlNmU3MjYzMmU2MzYxDQogICAgICAgICAgICAwZSAxOCA3Yg0K ICAgICAgICAgMGYgMDANCiAgICAgICAgIDEwIGY0DQogICAgICAgICAxMSBmNQ0KICAgICAgYTIN CiAgICAgICAgIDBiIDZmIDRlNTI0MzIwNTQ0MTQzMjA3MzY1NzI3NjY1NzIyMA0KICAgICAgICAg MGMgYTENCiAgICAgICAgICAgIDBkIDZhIDc0NjE2MzJlNmU3MjYzMmU2MzYxDQogICAgICBdXT48 L2FydHdvcms+DQogICAgPC9maWd1cmU+DQogICAgPHQ+SW4gdGhpcyBleGFtcGxlLCB3ZSBhc3N1 bWUgdGhhdCB0aGUgbW9kdWxlIElEID0gNjgsIGRhdGEgbm9kZSBJRHMgc2VydmVyID0gMTAsIG5h bWUgPSAxMSwgIHVkcCA9IDEyLCBhZGRyZXNzID0gMTMsIHBvcnQgPSAxNCwgYXNzb2NpYXRpb24t dHlwZSA9IDE1LCAgaWJ1cnN0ID0gMTYsIHByZWZlciA9IDE3LjwvdD4NCiAgPC9zZWN0aW9uPg0K ICAgIA0KCQ0KICA8c2VjdGlvbiB0aXRsZT0iWUFORyB0eXBlOiBjaG9pY2UgIj4NCiAgICA8dD5Z QU5HIGFsbG93cyB0aGUgZGF0YSBtb2RlbCB0byBzZWdyZWdhdGUgaW5jb21wYXRpYmxlIG5vZGVz IGludG8gZGlzdGluY3QgY2hvaWNlcyB1c2luZyB0aGUgImNob2ljZSIgYW5kICJjYXNlIiBzdGF0 ZW1lbnRzLiBFbmNvZGVkIHBheWxvYWQgTVVTVCBjYXJyeSBkYXRhIG5vZGVzIGRlZmluZWQgaW4g b25seSBvbmUgb2YgdGhlIHBvc3NpYmxlIGNhc2VzLjwvdD4NCiAgDQogICAgPGZpZ3VyZSBhbGln bj0ibGVmdCI+DQogICAgICA8cHJlYW1ibGU+RGVmaW5pdGlvbiBleGFtcGxlIDx4cmVmIHRhcmdl dD0iUkZDNzMxNyIgLz46PC9wcmVhbWJsZT4NCiAgICAgIDxhcnR3b3JrIGFsaWduPSJsZWZ0Ij48 IVtDREFUQVsNCnR5cGVkZWYgdGltZXpvbmUtbmFtZSB7DQogIHR5cGUgc3RyaW5nOw0KfQ0KDQpj aG9pY2UgdGltZXpvbmUgew0KICBjYXNlIHRpbWV6b25lLW5hbWUgew0KICAgIGxlYWYgdGltZXpv bmUtbmFtZSB7DQogICAgICB0eXBlIHRpbWV6b25lLW5hbWU7DQogICAgfQ0KICB9DQogIGNhc2Ug dGltZXpvbmUtdXRjLW9mZnNldCB7DQogICAgbGVhZiB0aW1lem9uZS11dGMtb2Zmc2V0IHsNCiAg ICAgIHR5cGUgaW50MTYgew0KICAgICAgICByYW5nZSAiLTE1MDAgLi4gMTUwMCI7DQogICAgICB9 DQogICAgICB1bml0cyAibWludXRlcyI7DQogICAgfQ0KICB9DQp9DQogICAgICBdXT48L2FydHdv cms+DQogICAgPC9maWd1cmU+DQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQogICAgICA8cHJl YW1ibGU+VGV4dHVhbCBmb3JtOjwvcHJlYW1ibGU+DQogICAgICA8YXJ0d29yayBhbGlnbj0ibGVm dCI+PCFbQ0RBVEFbDQp7DQogIDY5NjM4IDogIkV1cm9wZS9TdG9ja2hvbG0iDQp9DQogICAgICBd XT48L2FydHdvcms+DQogICAgPC9maWd1cmU+DQogICAgPGZpZ3VyZSBhbGlnbj0ibGVmdCI+DQog ICAgICA8cHJlYW1ibGU+Q0JPUiBlbmNvZGluZzo8L3ByZWFtYmxlPg0KICAgICAgPGFydHdvcmsg YWxpZ249ImxlZnQiPjwhW0NEQVRBWw0KYTENCiAgIDFhIDAwMDExMDA2DQogICA3MA0KICAgICAg NDU3NTcyNmY3MDY1MmY1Mzc0NmY2MzZiNjg2ZjZjNmQNCiAgICAgIF1dPjwvYXJ0d29yaz4NCiAg ICA8L2ZpZ3VyZT4NCiAgICA8L3NlY3Rpb24+DQogICAgDQogIDwvc2VjdGlvbj4NCg0KPC9zZWN0 aW9uPg0KPCEtLSBFTkQgLSBZQU5HIHRvIENCT1IgbWFwcGluZyAtLT4NCg0KDQo8c2VjdGlvbiB0 aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPg0KDQo8dD5UTyBETy48L3Q+DQoNCjwvc2Vj dGlvbj4NCjwhLS0gRU5EIC0gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLS0+DQoNCg0KPHNlY3Rp b24gdGl0bGU9IklBTkEgQ29uc2lkZXJhdGlvbnMiPg0KDQo8dD5UTyBETy48L3Q+DQogIA0KPC9z ZWN0aW9uPg0KPCEtLSBFTkQgLSBJQU5BIENvbnNpZGVyYXRpb25zIC0tPg0KDQo8L21pZGRsZT4N CiAgDQo8YmFjaz4NCg0KICA8cmVmZXJlbmNlcyB0aXRsZT0iTm9ybWF0aXZlIFJlZmVyZW5jZXMi Pg0KICAgICAgJlJGQzIxMTk7DQogICAgICAmUkZDNjAyMDsNCiAgICAgICZSRkM3MDQ5Ow0KICAg ICAgJlJGQzcxNTk7DQogIDwvcmVmZXJlbmNlcz4NCg0KICA8cmVmZXJlbmNlcyB0aXRsZT0iSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyI+DQogICAgICAmUkZDNzIyMzsNCiAgICAgICZSRkM3Mjc3Ow0K ICAgICAgJlJGQzczMTc7DQogIDwvcmVmZXJlbmNlcz4NCiAgDQogIDwvYmFjaz4NCjwvcmZjPg0K --_003_BLUPR06MB1763F35D73A9ED9A451915BDFE1D0BLUPR06MB1763namp_ Content-Type: application/pdf; name="draft-ietf-core-yang-cbor-mapping-00.pdf" Content-Description: draft-ietf-core-yang-cbor-mapping-00.pdf Content-Disposition: attachment; filename="draft-ietf-core-yang-cbor-mapping-00.pdf"; size=24437; creation-date="Tue, 10 Nov 2015 22:10:58 GMT"; modification-date="Tue, 10 Nov 2015 22:10:58 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WTXPaSBC98yu6cti1a0GAvWvHudkEe12xHRardisVchhGLTFGmlHmA5t/ v92DsMF2sh8EHRBi5vXr16979BV6SR96fDXfsmp1x8dQuFYPitbXVj/+Cc2XrOAspQVvoX8Aad5a 7enDwSEcH55AWrX2LrVHq9HDUBdKI1qlC0iFm8O5sRLhG5/rBP5EVZboPbZhmCX76V2rfwjp1RNk 570Vuf8WwsYntYSkhPZwg/7e2LmDSy2T/Z9XWDrDDJwXPrh39EdubCW8MlqU30U9TWCEpVms6BHW 8KFWFgnjWizhpA0Hvf7Rv2C3CSnnpTKM9d/2vWR2ayphxV34n1ikWGa0knBRTX+Hn2Bg4MPFzrwA xgmkgWpnd8e6EjpT7peL5Q/AIsHOFFLZ9Q/I8VOoxF9ssp2wRgkshIYMLdx6M9+d18BoF0pPXbAL 1o1ZYDUlUkfR378RFjf61UvEwdnHMTW9NBl3vMnhvfACrk2GJbXbvfIz+HR6w6Zq2vr1gAp93pHG YmcpdNGRU2M7lahrAqWtB0dx6+nUeSvkOrN0phxkRoYKqeczzGnwOMA1FxtK+kltDhZralhaxI+l 0bkqgo29397ixcMBIaME2jAeDUDpOnggA4IJnm9rarYKaSy5dnysjVe5khFq7YMVjwyC42icOwjH ZZHKIflPC7uEj9M7lB7Ga2IRASZ7rOZkv0H6PD4fHPd+PfmSPElwG+cX6xyzv8bKbKrxbGbSExem laLpmlE2kIeyjALw7NM0lmN9/Ay3ZKitWSjHKXGcs8EIjt/GdOPtyQYbWrwd0YGwhEptwcmvaxNx KAq8dkpshd44MSZ7l8P0fLKfsBupLH4mPBhCsVBYE2oHFc1fUToDNCC8VdPgsdHiJQHxXBuXsGQI Je1lejJYyzZ6XNVANWmRkhR+5n39rttlh7AR52gTNm5ibNHN4sJug9P9Z5Xihg2KC1GqLPpVUGoP qgoVE3PqASqj/cxtKcX1YAGmCKEmQpi12eelkHxHIGbqDJ2rVPjpstFtQw629bJJ0asKSY3L6Bfy Z00GqK3iXvCGfIwv6TuKlSMlKteS01lK5aSzlELTLqliybBqQlP1NG97w6VhK1KMgrzvkjdbQr3m 4ns61gHjqQvUJRvHbjyPB6ZeWlXMPPtEPRJ6ejzZk5P9OMaALUWnXnCrtmZP1tTNbHWV8YDIFQlG PJ/3xOOYEcHPjGX3nBKrGIDFcGgXGN8PqFd4z8ZrDfldlMnTrGteIL7//vB5JAqE/hdCHKatP+j6 G9glhDVlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKOTYzCmVuZG9iagoxMiAwIG9iago8PC9MZW5n dGggMTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydll1P4zoQhu/zK+YOkCA0 aWnL3hXKrpBYYCE60tHZc+Emk9arxM7aDpB/v2Mn7TZpESmJ1LSN/Xje+bJ/w8APYGDv5hnn3vnT BJbaG8DS++0F7iU0jziHq4gGTCEIIUq9ek4A4RAmkylEuXd8KwwqgeZsrlhqAOD66uEJbkQsEy6W IFOYM8Pgu0wwwwReuVnBv7P7bzTyXr5gvkAF4SC4OIl+ecNLiO68Y3oVrbiGRMZljsIAfdfl4hfG BoyEq+tHoMWZSMCsEG5voq8QqVKbIw13uGTZyZEXDNekRyVfuOZSaHjCjBlrFEHcrHmzgKYZduzP 45UxxZfzc2NxiD5Hk/pSLc8zHqPQeMZFKn+eABeAaWrtkcIZkTCDpLXhFOWCJtBa9JYcYLbF+GRS hkwjKHzh+Gqn04+kY0rMFKZlllWnwLQdU0GCOlZ8gVDJUoHiy5XRzgsKtVE8Nk6kczD9U5B1DYvk dk24pnDQR15IYRcFfDOKxYYClCqZt4dDTs5oUFzEWUlTn3leZDzlNOHqeQ53tXvAEMfauzY1sZ56 RmcajPwtF1mnuaDVIdsOk5VE6qGwfyVNzsjSwCtTiglT0QoNpbWORe63y6fh4dhlRMQWmTWDxFPi /vV3QE6hVFYyKWtrwT/wBghbiWeZlhqhyrmQmVxWBxOHjXWh47yZkjylsKDwkumb/HIVFzd6PmQN 6YcrQEoLNzNnRWGr4gC7Rg3L0oI1j7I6/YTXLjasmrbhmarAL7Dggql+nttlhV3Wu/75mDXssKQk wb3yBGDcYY3arARjnrNsPPqYtsu6aLMwL6hCemrsssYdlqAGoFifegCYdFiTNosqWRhuKmprh7Om HZbQhomY2rGDUrmr95gA0w7rsssy01P7GYzdYxi6x75Y0K7YzdWBv82yFdBD3zusoMWyLZ2Kslcc g6DLClusshZZNirLRma5R+ce1rDNEr274x7WqMVionrLs56ssMu6aLFs/2NcvJ8J26xhlzXeieNZ xmlz6sEadVmTNsti+ii0rJ1eOG1rXEna0Hqy1jVkew1twaWi4rO7nqaiqWu6dy/csGyvuZ3dzz7H qVnrerS95glTVEiVrA/fb7dZlmb3jXupcjLpBQ8mt1mhOw2kn6T9Zc1KOrkofQSzJKFNWx+us2Y1 h5fuIaVZJXqA+YM941wGbtg/yLMMjcFTQDqOZT5srpu3gpMh8J1VcHlqD95j2Ln+e2RLhPB/It5E 3g+6/wDrjN4nZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago5MzkKZW5kb2JqCjE3IDAgb2JqCjw8 L0xlbmd0aCAxOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nGVU23LaMBB991fs 8FIyQyiGNrc3QkibGcAJcdrJJHkQ9hqUypIjiRD+vivJECD2jHXbPd49Z1dv0GnH0HFvPWZl9H16 CnMTdWAevUWxP4R6yEq4TMngDOIupEUUfGLo9uD09AzSMmreSItaoj2+0qywADC4TKYwlJnKuZyD KuCKWQZjlaPAHFbcLuCxP/lFlhP1juUMNXQ78c+j9DXqnUM6ippxO24DpKhLLpVQ8/XRt6h74o/I K10g/MM1rJTODTTGD/dpoxVGmCR+Ph3ePdxMh1dufv+7PxptJ8GC8OLeBo8OkodRbetmnyiDZDwe Tq4C0Lj/SAOTOTSS2/QmmfRHDeAS7IIbAnRQucqWJUoLTCNYBTMkA6Kn0mgpd2YgR5NpPqMFeT5N rwfdOD5/aR8kyA2YCjNe8IxZriSU7B8aWBp0fFoioFBCqJUj2H7SdFGHoSBwLonzC+j7MUSKgXqT LbBktGYWMiZDnMYyaTmzITa2xxEERGOVRpImkT6QTEnLuETdAoGsCN9jwY2lqf8qTYStP0qxnyEF OFhwkUO+G+Z2QSwVBBuKxcXy+SeP6MEP4yPOyM6jeo5oveflfNqher7sw1ZBehxLFQlIMtZkbwP7 ksVNTmYkE2pKQALfLoEKmxqARHMAXBZKl0FKjW9Lrik5qw5TyCkUknTJzQJWThvKYYZO5C1wDoVW JTAhQBGydonKuamZ+kyCWyqhTFVep413KKYvSdyGZHe0uEc8FMh5Nbu+LT/skgnKg6rakGNIi37j G99xS5sbPgcqGQG6y4CoqNhaKEZN65rI8dK45ihy0yCz/i2oyiMtjS9rOh4omXGDezRdcsn0GpLZ K2YWpvtBPDddDM9HodNCDc3Wvs9OOz+ozwD+7hLlq2TTtK2wnIUf4OYCo61tqgQXomMbBCfmOxOO P1sT46Ru1128u+eQqINzMFbzzIq12z24OEIa1VJXymDgibwkvjulNZOm5La+ScwyWzhReu5mJm7+ IBcC6bQFSBeQaMP2GX5UVHEGxmwN5y13257Al+fpls0Rei8EOUyjO3r/A2tS4I9lbmRzdHJlYW0K ZW5kb2JqCjE4IDAgb2JqCjgwMQplbmRvYmoKMjIgMCBvYmoKPDwvTGVuZ3RoIDIzIDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicxVfbcts2EH3nV+zkRfZYlknqQilv8aW3aeTUUdrp OHqAqBWFFARoArSlVvn3LngRJUtVXOdGPmCHCxycPQAWyztwWx649i3bMHbObgKItONC5Nw5Xu6E sgljOB9Rhz54PoxmTjHGA78NQdCHUewc/SwNphLN6WXKZgYALs6vb+BKhmrKZQRqBpfMMHitpihw Cg/czOHPV8MfqedQ3WM8wRR81+sejz447QGMfnWOyDWaI8yUEOrBghg2EQg6i2OW8r9Rg5lzDSkm KWqUhhmuZIsGKZixkAtOX/C44XjtCo4bDZmcYqoNk5ZXcx9EOaOFR/jl7fUQ9JJcC3h/9DBHSYgW K1Fac+Lz/hhub364CLzuYNwin9+rZjs5XT8nW82+52S/fbLFf1WoCrW5ghEuzOMAyh5XCxYnpNj2 wJL/CkJFayaNNc0yQWr+81lt2VitaoX1pSIteL2TmkeSNsmKNln+5RJDHjMBUx7ZJdzk4tEeXNt9 CCbbMXIKMaKtVUXw5Bhrc4312Ps5WEOMaKnureje3hhpPWd8QSKQ63Qd5AraFCP7VIyTJTCIucw0 WClb3yfG86XB0usXzU+4YNMyznsmMqzHzxsw87phw9odP7c3sbRJ7Ybb4EWbUChNAk3QPCBKilRG drM/I8a7TBlKJ5QTat1Jw2dhMQmNeaMFO8831T7PCoW3XTRvCwUpEb+TnM7vhvYvzMK8KO1eewdr V/twzlIWUsLX9TLs4RV0gn7Q+USM1fJNVWaze7kU31qvV2nKloW3UzQXiq4Z0JhQqIbiE1xXit6C 16QtPbZ23weXrkP/IC8SPd/uOr/3uHw6r10sfZexFGFCC/AXGv2dzvZrllTebtEc0OufDSzmP4EX 6SVZjGdFjkgYTzd6eC9t0m9a2/W8vs34h7BKxcMsFctcNSw1sz38l9Dp9nLb9b2B64X9Z+r18bBe /wtrr72RV5USSGnGnrAz36VmxoTGxzjF+NpFducQL8LyqDFpthdqy0VY3a8a4zATouZFpwtk9WUX q3YRr97X5aVM5SVebWpsPTnjssqAm+NrF/EKdrCYXtc5n8nrS9VfZe3apgOS1+ZGFXVjzJKEroBy tuvJBwypRKmCy3RenFOxnA+KbYlvvwgmo4xFCDZf5TVj1XmrqM1nyEtotzMYw4TZ24SKWAuYZgLr ibgsynVN0xel/h9oVcxiLKmZOTPFQKRCIwXqzIS1l3QQYvolYGnx6zFR1f+Hnbnn+u44v/4tmRJr TclW9b1uTvd35EKgMdgENAS9cc1fLRJONThlxiUMmvZfpgc7z+0bq0dnTIhXI+c3ev8FA3QFHGVu ZHN0cmVhbQplbmRvYmoKMjMgMCBvYmoKOTk5CmVuZG9iagoyNyAwIG9iago8PC9MZW5ndGggMjgg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVE1vm0AQvfMr5uZYCi7gGBPn1Hy0 qhSnrUtbVUkOCwx4U9h12HUSFOW/d3aNXZPUTWsOa83He2/eDtyCN/DBM097ppXzZjaGQjkeFM6t 49sktEdawXFMBRH4AcS5s+rxIRjCeBxBXDl7H4TGWqB2T2uWawA4Of44gzORyoyLAmQOp0wzmMoM S8zgnus5/Hh78Z4qL+QdVgnWEHj+qB/fOMNDiM+dveHAH8CqqESW93tOENoE9cRztEFQmmmsUGjI MOcCFTDIDJMgJmBKyZRTRcvI4I6VSxxYAAL0h2vAXJalvDdS1TJRmGouhSJMldY8QdDEh1vDZDzP sTa0VoVuFqgGvxUa6RvxJjmBhAtWN1Ri2M6pSRkck2tTMP36JYak5SHFS2XI2MrJpNFIw9YmZObr iOdkAVztVexG1itI76o/6Bh2atzhZirAB1YtSpy0WuwADJUfRO5PbOCxAw0diY9tD9g+UZClfni0 CT61/566d4UPeslKsriuJjDv+bmfYsiG+UEQhl4WRVF2GLCDLPKG3sE4xF6LYudemz6BEW3cK52m 0VgfPLdeqx3Ga/V/tlurOwa9sB3g2MAupFrZ7YGWMAZW23XkhSAOipiNynmttOVo5Zkl5cLmtpj3 V0Ij0+aP1s20pFJktm4fmMhaCLu+t0uzmialusSKV7xkddmQzO8rMmTpvEWxNFTfQm268lpWZk9I LJFXkk6T4TlPmdCvLRpczt6dhF7gXXdWrmos3Y51azPrZaMAvXOKJSW6ghUEup2FLbePtuJPzxDY UktXoVDoqgXSYDtA/L+B+J47TVwpymZXe/Dn9n97O7xRj3ZqhosaSSnZYL3ozk63vSWjY6BCfdWn yCiwkW/IyxK1uVyk+cvBRi2cPSw4ccCUNXC4bz6+Ibz4XX5iBcLomhDPYuczPb8A9cTBRGVuZHN0 cmVhbQplbmRvYmoKMjggMCBvYmoKNzAzCmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJydVMFum0AQvfMVo1xqSzZlsTGxc2pit6oU p61LK1VxDmszkI3YxYElsZXk3zuLIS6pXVldDghm5s2b9wbuwbEZOOaq7ktpvZ/5EOeWA7F1b7Ey CNVtKeE8oIRTYC4EkbWtYeD2wPdPIZBW67PSmCnU3XHGIw0AF+dfZjBRyzQUKoY0gjHXHKZpiAmG 8Cj0Lfz6cPWJMq/SB5QLzMB1mNcO7qzeEIJLq1WDYAUygj419trvLHdQJvRsZvds2OLozQpHsEjT BLmiHFN+iTzKTW8TrGMw/fE9gAVucYlLkRuGfNtMZwXCvCX5XZqVZQTFejUfvwM8DIUWqeIJCBWl meTmCVw2bwOVRDzJEUIzq9AoG1BUXhE7BOLM2/ZuPkocYyRUmQq45nKVIFzPPl74PebfjCowGiqi YfjCCPvU4AuNyc+qgpdGiwDXuiAihsaonL9KeyN+ZJQvNe83NQ9xKSRPBv29qr9G/617oXIRK3or aJFizBpjHJDz/9WSm27Fa79gO9JPVZk5UcaXBrwbiljoHNyzP4IZVzHCCQPbBhKpD8/m63kmT21b 8vXJLvflCBtcz6dZZ7jKMEdFvWq6DzyhBXVtz5+39/vEhuAwh9VmeU2zUK70Zq9RZeSASfoWt21U kdQcKisa8lVbfnC/3WMdc/03jom8m6UF/WP2G1aSP2a/zQAU9twy/BNFkqDW2AHUwBMbXs9kvRIk Pkz5BoYd828awF/n+isn0wc3hDgJrG90/Qa0On0kZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago1 NzAKZW5kb2JqCjM3IDAgb2JqCjw8L0xlbmd0aCAzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nH1Uy27bMBC86ysWudQGbFeyGitxT82jRYE4bV2laBHnQEsrhwlFKiSVxDDy713q 4UfilgIkgTucnVku+QD+IADfPc03yb330wgWxvNh4T14QRWE5pPkcBIT4AiCIcSZV68JYBhCFB1B nHudr9Kilmj7Z5plFgBOT75N4VwmKuVyASqDM2YZTFSKAlN44vYW/ny6/ELIS/WI+Rw1DP3gsBvf eeExxBdepyXBhmQM2aj7zhuOqmg4CAajAdQkdlngmIBljppZriTh3PoLZJlxyR1gOw6Tq58xzLEm J0GlcTJZnbGUhi8kpsQShK0WTg4XpDJ1PrjFHGadnN0pXZP7s+5go47wZ5hxyatk+MzyQiBcTz+f RmEQ3YwbfYL0gSpQ941ltjSw2kkJb3WvmpVuuHkoC1jBIxMlQvARXl6HU/Uk14DhHoBFY531FhPu wZTyXm7zfNibSOdM2jXmcA9GKtsvNBrcwo324IR6opIItqT3joFoG9z+veyUPcZnWzIBGekZQ0ib NMUmp9mpZM140Pg/mHUbulc954du3nVbtNttPCVKbpcas73dthX/f7dZUgzGapra2f1/NFpIjQZw JQW/R/g9uejVLKlC4woMpiwKpW2jSbIcTcESNLQoVkBnTScqR7C33IDgObdVOXqtXk40TK+lNjSt 4ETJhFmUdQmd1duN0yrZrGNm3TZC3lET05pnk6RHpyIRZXU7OOicmS0mJlMwWDDaKyrXfEn2bMVc nzG/qtEv5EKgtUhcFpgYwHqcPxecNh0mbAnHPXezjODNuP7OFtRTN0R5Hns/6PkLAIJ/k2VuZHN0 cmVhbQplbmRvYmoKMzggMCBvYmoKNjE0CmVuZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMgMCBS L0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVE1vm0AQvfMrRrnUlmLKgr3Y7qmJ0ypS k7YubVXFOaxhwBvB4rDrNFbV/95hwXFdf0iFA6PdN2/ezr7hETyXgVe/7TcunNfTEDLteJA5jw6z m9B+4gIuIgIMgfkQpU6Tw8APIAyHEBVO51oZrBSa3qQSqQGAy4uPU7hScZlIlUGZwkQYATdlgjkm 8FOaBfx4e/uekLflExZzrMD32KAbPTjBCKIPToe2JphKJY0sFeCzKJY5wt303WXo+8H9uPvK8fkG KRNURpo1yFpIKmLsmfUS4RehWLBB/T6SI5TonUwEmAuN/5C/IcgJVjQL25JLXYg4OUK4X/kwa44i hYPC7OKmaIWpBTRbJ1U3FfYrRfhsViKHtKyKMZwdUOjunuyspbE3ju2Nj4GM4fs7WvmIM46c+QlF GPb5IPQ5p7WAD/wk7Iej0KMIab3Ph3bXxv0gDHhicf2t1MBl7tCFxkW1rDEdVBuhSGXTjlRi1Wr7 vkAFoumiIg/Whmwat58CL6GmFE2HyXHnHJscSGpLW7pZZxur0sBSVKauQSWlNrPuOUij4UnkK4Sb r18imGOrzDaMJmJVFyK87eJKaZkpWq0bn5Ekyy4NFlSpEA9l1aj3Zt2WJi6VETQrxEGXA0ZUGRoi 2Mq6nrg793xstgIW2tn6i5UE6LWuq2+9ZVtp92Oz58nWldpUJGjXcFsBLcei1EaJYt/YG2uT0cZJ WZCOXo37P/+S04LBYYMyAZ7nMeZ5AQH4wBJ8Q5nnaAye0/yCyF14ea6el7IiT9yINYzO678Vh73n 7pPIEIb3xHgVOZ/p/QPuiIGMZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iago2MTUKZW5kb2JqCjQ3 IDAgb2JqCjw8L0xlbmd0aCA0OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1V W3OTQBR+51ecyYvJTBIhacml40NvOp2xVSvqOE0fNuEAW2GX7C5t0fG/exZIWtJWhQdYlvNdzgXW 4A49cO3ZXFeZ8/pyArF2XIidteNVm9BcVhkcBfTCFLwRBJFTx3gwGsNkMoUgc7pnwqASaAYnikUG AI6PPlzCqVjJkIsYZAQnzDA4lyGmGMIdNwl8P7x4R29eyFvMlqhg5Hr7veDGGc8geO90aetMgEm4 BrxnWZ5in1YItywtEPyZP94HHqIwPOKoqy0utGFihZbPrkPi7L1yvPEGUBA/dBKpjWAZdiodXNSx aKKBLrXBDDIZFikOAQ61LjJroH4CZyfwhgAtlD8FJsKKooa1ezAe0vbI3/B9S1AAgxRZVL9khZX5 g9LB1oF6bIY94Lb06yLPpTKVoiI1nJKyhdKw6D6oyZkylo3IuTaLXh+40XXuGgPnXz4HsERAWySq SaEtLKsrx5RiZS2C24wsuhm7kaoWv7foNRgrKQzjwgbaHEYyTeWdXZETRUbmrWxI2MAXQvNYECmn vonJ+wtM7qK3w9FKBx1RkablYF2w1GZupx5NGximYjSPN4cv6PqX7V3DdS8SDbJVsivtB5agcF1w RdRGbupbPtuqz2tskIIENVo8va2aVCFaXKYhxIjXuayQOvRepx4uoiAXxNp/wKJndQNFSmYkK6fu vMW0apN+1dJ1FWFZVq4agY8AiiWRc0HQdW919aLXTuiJVcQNl2IzunB1+fZ4MvYm1/MGyYZSz1Ht f+0kzubNjudBCxOaKaKNJxFQF0hTz4n4YCv19/auCs2Z1nckvQpvBXImyOl8pcrcDBKmkzZGS4SV zQqTSMV/YjiwYp/KecnC3028YOOxkQaApTHxmyRrefn/eNI3qBrtmfAllVaVT7PYzkSA94aGjppF ZXO4os/xZNaHq85SLjt96LCQPpud6+smthoubP4Gc5iOwGPguq7nuaPILv0x+CM/8uluH3zP3/ND grRdR2tL+RV5mqIx9BNAKkA63IqG0/ucRoxGg0aXNNBvxIcnx9VHFiPMrKDTwPlE5x/jkAFfZW5k c3RyZWFtCmVuZG9iago0OCAwIG9iago3OTkKZW5kb2JqCjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI1UXU/bMBR9z6+4ystAakI+IC2d9gCU TZOAbSybNAEPbnKTmiVOiR1Gmfjvu3bS0nSRtkaKa/vcc8/9ygN4rg+efro1Ka2D6zHk0vIgtx4s 31xCtyQlnMYEmIAfQJxZrY0PQQjj8QTi0tr7KBTWApUzq1mmAODs9NM1nIukSrnIocpgxhSDyyrF AlP4xdUCfpxcfSDkVfWI5RxrCDz/aD++t8JjiC+sPbqKF1wCPrFyWSDwFIXiGUcJakFbIRUTCWpu vU81vyB+sH/iytFbe/+N5YdrMu2Ti9YWVebIlVRYQlmlTYEjYFJWCWdqra6RJEmwkvjm1dwGJlKi 00SsUYuq5s+YOuSpw7C05MJ2AU6kbEodc0sMH2fwDqKJtn/V2DGZu8OxS9sgMjpD13ePicXkRq2W OKVA1WSk335kljAwS3TYkVwgy6TJAsEH0MazMYDLb19jmCOgrgsF2kgS2ksSUugUt6leIyTPBRpj zOn0dq9k91XdOvJu96HqkH1cp2sXPYIUlyjafmjrwBLVsAIeWdHgVhLIeIYZF1xxAq7rf3P9/mwc +uO7aeegoMBB8RKfK4FOoxKnyjKJCn73QoJNYvzIXLWHADUTOVXO8Y88D1wX9Gq/3QBeun8vPWEx PhnNWVWXU3BCz+tgJhHYNfwUqIk9P5jrS11T3+sXVWuvMRssYXc3XC2Tt5oaS243fi9gMwREgDVZ kt18ZXD2kqmF3Yqg0aHep3n6v6wHQbjJupaYkjpd7DpjCTqGzNGKBxO/Dmc79VoK2AcbDtmSvB4c 6Kn6ZzGSSijGBbXmLtNfUgou1SuqJ0YPsb3jr+suM9vb2C4mqWqqxTb8ZcfUMQ4XPKdxcgq2ojfP hqgG8jjMu52C6MhE9h15UaBS9PmitmeFu6GG86clr6lJLtkKjkf62xrB7u/mM6MB8L07YjyPrS/0 /AECDbeIZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago3MTUKZW5kb2JqCjU3IDAgb2JqCjw8L0xl bmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nI2TT2+bQBDF73yKJ19q Sy5lWRuwc2pit6oUp61LK1VJDht7wBvB4sCSOqry3bv8cVJSKgUOIzFvZt78drmDYzM41dvGTWq9 W/uIC8tBbN1ZrE6iDZsUp6ERBGAuwshqahhcDt8PEKbW8JPSlCvSbxe5iDSAs9PPayzVJttKFSOL sBBaYJVtKaEtfkm9w8/3Fx+N8iK7p/SGcrgOm47CW4vPEJ5bQ5MK6aBLkSDK8nSOAekds5kzGL2x XO+oqQdRO2gOz4c39SdewJlLnHHHiIfcNnXMRjNSP+xpjkLnpqDKmibnJKKiclnl2hRW37+FuKGm uTFdFtVX0UzUxtpRuDWrmUaMHz1JTSmuhqm4zfKmJb8a2R3bC4qkklpmCnQQ6T4hXK4/nPmuy6/n ravEuIISKeF3pz3+tnnSih877f8lV2PrAzY5AntG5XZRlVLpYFwH5jWRu030Jr0Eeysg1LYt6mfb WbLlXKpCxsooTB3F5pZUsHsAO68G7PtdwKku+/k27utc8xXIhYoJAy+w7VQcBidPqcdXnAJzA6f/ DNgMztR55s9f8Fdmi37OVeY/F1XvCHmZUAFRFNlGCt3+eJ1dM0V1NyOuOyayMLoKJZs2e/wgmSSk NY1BGiKx8fQsD3uZmwEr8YDZuPqBPbx8Lr8Ig4yxa9NyGVpfzfsHcuw54mVuZHN0cmVhbQplbmRv YmoKNTggMCBvYmoKNTE1CmVuZG9iago2MiAwIG9iago8PC9MZW5ndGggNjMgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVG1P2zAQ/p5fcao00QDN4rhJS/hQ8TpNArZBNmlqMsk0 TsmWNxIDRaX/fee89I2ARCL5nLvHTx6fz3cPukZAl29tJ7Hy+XoA00LRYarcK6QMQm0mMRw7CBgC McAJlGoNAYPCYDAEJ1a6XxPB84SL3mnOAgEAJ8ffruEsmaR+mEwhDeCUCQaXqc8j7sNTKO7g99HV F0RepY88vuU5GDoxVeevQg/AuVC6GDrlQZiEIkwT4DMWZxGH8fX5yYCSgWerO4phNUjxnHGfBxBm j/0e8/2cFwXMEUJoA6lAUIhcKpKxypsxIbXDjtt1u2O9d+C9jAmO1ZSUppobaPrN3ERreq7qupqr zuliybd8arYPkXU/jV03m1+10aH/YuHtuepo53AZboCLt9JhfTAdWwmxX6RE1guOeufeXN/vL1zV lkK33ehEay7kojr6eg8AmytG7T9w1ZeKpk7MMlmtjPLAdOKNylxW4+pYXnOs4d+gW3Ko6yfSnv/t +vlje3syFdZi9VmO5Z60XdSFg7q2x2bJbg1rEzWy7TboqNSnfbAk3i+Ih0Ret/V6KN3rF+uwJWi9 DrbriDgL4F0FIfYReyXzsJXG4TPxwCII0jy2oTM2dJ3Y/u3Q1m3i2UO9U68q+xCv+5ANAwLmLTWo ji+hzOpbBh1Shl+MEtPHcUjLsqAa0Uhfg6pLSV02sOR5Fkc1sXPHoVN5OniLmOAxTwTkPEPROCsQ jsn8l6RPCfiy+SXY/LRqYSNoY/vYJMVdWKzAcPnzxsEdRlH6hCEO+UPEC4lLE17BeaVv+f+iVheF hcA+GyZwwydlA6XaRv7eaK2Wbuhla5WYanelnuYQNtNODIp+yyxJf/EwijjehX3gAlikrcr3bJaF mBW4ZM9wsC8bvbVd4TD+zqYcGT1kPHOUH/j+B8aJvZ9lbmRzdHJlYW0KZW5kb2JqCjYzIDAgb2Jq CjY5NQplbmRvYmoKNjcgMCBvYmoKPDwvTGVuZ3RoIDY4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicjVRdT9swFH3Pr7hvtKLJmmQl0D1MQNmENNjGskkb5sFNnNaQL2IHqBj/fdeO kzQdk9ZWuonv9bnnHF/3HqaOC1P1NTHKrDdXAayENYWVdW+5OgkmRBmchFhwCK4HYWI1e1zwfAiC Qwgza3SeS1blTNqLiiYSAE5PPl/BWR4VMc9XUCSwoJLCRRGzlMXwyOUafh5ffsTKy+KBZUtWgTd1 Z+Pw1vKPIPxkjVoQZkDm4B5CsBzvWd5BW3CcqrZUMnigac3mmFTLzxhdvy0CpDoHb2KSAB6+zmbm 9WUAuNORejBFtZ76YXc/UJt8x3XcmQONALkp2RyiIpeU56wyqMf9Clx8/xbCkjWwKL4WyhLa9Mpo CbGyhkuWARll9LaoNOhAw4yMHYWqyrlA8KysuEAwdLakvBLqocMRk8ZhRqN1v2qoITHBhTTHQuGO bYDmMT5pDx3oiWFKvE7fYBkRNSKucsxxHIMVSt7WAVMy1g0EkyAL3KMZ5QgG5wvAKmrQkjpNN/Z9 TVOecETbrkNai63XnlatXHhcs7yDKWnFctlUsieUKnR7uUbjTE6sMQpcYiBoxiAr4jrVdKheba2q K13eEdk2R7v1D3s0coWQojVKiCLiOKhm9lW+l6dscgZzuGAJz7nkRY4SaFYiueurD6eB7wY37ZSr XTHTx85sVGhLjlJ2Z18fgZCVYvXcXQHlklR3B/YIiZ/fvtgqeG0ImzAfBDIixMHHfTJ+T0a/fl8T sk+IfbMF2n2GG8d777qil1fvXX9borSI7v5SkTKatMdhK8Gd1ra11jmwYtiz72XQlkWxA7Xd8P9A WyHurEH/wXiaMjR2AjjsNHV6qLOnkquZu6AbOJqoP7uDXdPg+gtdMXB9ZelZaH3F7x/S6JhTZW5k c3RyZWFtCmVuZG9iago2OCAwIG9iago2NzEKZW5kb2JqCjcyIDAgb2JqCjw8L0xlbmd0aCA3MyAw IFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ1UWW/bRhB+568Y6MVWIbJ78JBoBIGv BgZqN3WYAIlpFGtxKDPloSxXtd3E/72zFGVRjtMC5YLL3W9mP87O9QWYx4HZ0X/nlfPzZQSL1mGw cL44vBNC/5lXcJSQwhS4gCR31mc4CAlRNIWkcvbPaoO6RuOeaJUbADg++u0STut5kxX1ApocTpRR cN5kWGIGd4W5hY+HF29I86L5C6sb1CAYD8bJZ0fOIPnV2SdRgvdmpUrIG13F4z1HhBvJV9pxudkB hLMwjCDu8DUCIEMCRpbV5cxlIuF+7Eex8D+5LIgZG02GytGTMpu5PEjYLOYiDqYb5Sfdx371uGNQ d1/s7xv3Koo/M5MrYIxxzoR84lNiYAafgvAHe3IvnZFCMsllIDKaGc1MisCntS8VvRHNQvqB6iQB 7Zhkz0iDfyNlctZRB0RKayLgJFVENf2OdHvlsxrMbdEC3qtqWeIE7hBU264qJFwZmhCqJluVCGcn 8ArC6QQymwU1ZQFB7Y5z5mUz/5O0ZDCB+UprrI1L2mgK4ntlg6nqDG6aZgDLyNtaJD3u8dCDdV6Z hyXGUKLK3bJoTX/7wy0C5+/fJXCD66BRTq5am6lqHUmltXpYW1sYrCDdr9TnRne0O2b76Zh+earm t0Rk9MMPaK0vNHmihQzzoib85qEDe0JL1S5xXuQFZt6Om0/sgcIUTb3xNFxd/nIcSR5dbxLNshAx ZE2litqtFTnneYlYHWiNtuYMy6TEekHVOOKeJwI5OhiIlsrYsoa9dN+OK+X+feh+Yu7sj+vhLk1d AsZf2STkj+n49VZy7aXjAd/T89P/IktT7/VLbOn4G4n2Dv6jRLehb1FpCtiLHhq4cEvY6Aw1Zi4F bdWiPniRf6dbwRWMCjS51+jFaGLXiN0arvvDux0DpoIKxPaxIPLDUGCYR4JaWo/ZscHofBh0P/2A RVkixWgCaECV3tYnp/fLQlO6nVMazya2t4bP3QZXb9UCgfvWotPE+Z3GP1FWhMNlbmRzdHJlYW0K ZW5kb2JqCjczIDAgb2JqCjc1NgplbmRvYmoKNzcgMCBvYmoKPDwvTGVuZ3RoIDc4IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpZRRb9owFIXf8yvO20AqGYHStOWpLWyatHYbyyZN pQ8muQF3iZ3aTls08d9nh3QFku1lBMmJ773fOdd28oC+H6DvrnqMc+/tLMRSe30svQcvqIKohzjH ZWQTThEMEKXetibAYIgwPEWUe50PwpASZHoTxVID4Ory0wxTEcuEiyVkigkzDNcyoYwSPHGzwo+L m/c280Y+Ur4ghUE/GHWje294huij1xn6gR+EPrZ5Zl3QOTKuTfeNNzipMmzxRTWF629fIywI5AQt v9ROlW1dMKXYGonT54ZyzDs5u5eqQuJ43vUtMRi+EKcsXlmOUWvn2qy4rgH2phWfs6IJt0gHqyRG 8y5SmWXyyVWZFUGznKDKjCzb/rcdxlIYxgUpf6/DCaVccMOlAD2zvMgIt7N3V+EwCO/Oa5lqDTSp R7uKv/a6AX7SGsLqjfeotoZYWgUaFbVtbZT1O64lgM2fu3gleUwwigldSGUqwkttzDShTIq9Sbx2 1xKrzbAkUaR1I1j7WUltxo1QzoRdfGl3y6iSDuObNp2G5R0RF+uJ0p3Hf7N2nzYta7TtSGsZc+Y2 r1fhd1WrCbJapKqMA0suUu/puBkoqH1aymzc6gxIKGVlZhrMA898USptmk4XFk1MjFuIKcs0/RVY KErrc/mfQDcG/ePqpH4nnmVkDB2BDFjmv27U9Lng9iDh2r60Z0fus3KCw9/tZ7YkBKM7i5xG3hd7 /QYPXk+pZW5kc3RyZWFtCmVuZG9iago3OCAwIG9iago1NTEKZW5kb2JqCjgyIDAgb2JqCjw8L0xl bmd0aCA4MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJVUyW7bMBC96ysecmkC KC5JSZRtoIdsKAw0aRsIBYqgB1oaOSq0OBKdBUX+vUMvSSSnh4qAOHyzPs1QdxAjCeHWdk8r7+N1 jEXnCSy8O0+uldhuaYXThA3GkApJ7m18JFSAOB4jqbzDWW2prcken7cmtwDOTr9e46JOm6yoF2hy nBtrcNlkVFKGh8Le4ufJ1We2vGruqZpTCyVkdJT89oIJki/eIasSerQrUyJv2mp69MFTeqf5wycZ 7E6AnuhQYYobxjfIxmYnA1JOcXB1fYZkdoaO2ntqD/y+hQvQd2IwYDdbpKO6TUepGbiwPpyyY9BD nwdxI44rBphmLDdlRwM8Zty2K3qD9sL9i9TJ/5MyL6T61b9N/SL/2krPvTasu0zbLk+3JkYOmgNp IISQUgjzGnysemlNNCgSYg5NCClSYaBEFIYTt8eBjmIVa/fe80hh9kCHZ9AGcchTEijSFKv1Hmj5 njFBjhHP94LnTGII8g3Jwz1QIu+z2a/KkcvfkpNDcmovmaP3bsU7evIdeq/NmtWwt0UHejTVsiQf DwTTdauKGDeWX4SqyVYlYXaOT9BjH5m7tTXfWoa6Xls308ZmUvioDQdhUfpYZUsnKR8my1rqOncK fCyb1jox3M0np27SwtiiqY/t03LtH/ko5qu2W1tqdmop3ySJRy67CNfpf1BRlmQtcyALU45ev8XF 47LgrLg0T5j47p+iMXxuvpkFN1m7mb5IvO+8/gJZ0RBYZW5kc3RyZWFtCmVuZG9iago4MyAwIG9i ago1NjIKZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0aCA4OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nH1UUU/bMBB+z6/41JeBREPc0KSFp0G7adKADbJJE9qDSS6ttyQusQt0E/99 5yalS8eIpdjO3X3ffXd27hD4AoEb7ZyW3uFVjJnxAsy8O0+sjWintMRpwg4jiAGS3GtiBAYh4niE pPT2PlSW6opsf1LL3AI4O728wrRKdaaqGXSOibQS5zqjgjI8KDvHt7cX79nzQt9TeUs1BoEY7ic/ vHCM5KO3F/rCFyMfjZ9dLegY6VyrlPbfeINo7YPWKotCPxjYOSFzPKXjgdUwNKtpJi1BcS7lQlp1 WxAqthv+ZDVjiXCDlSlj2c+2PAZL47J3sL3mUw+yyngjDS+NZeCSKms4y7VWyhjPIS3kqtAyw/mX 6wSprOtVk1hDnFGuKi6DqqCrYsUvciVyPAttjEuxxXFExu8InrhgZZWuQI+yXLCcm6t3Z3Eo4u/H bZirFpPAqpJ+MXq/kiXhd0ds48UiatZ40gY+dagazc8o/wC47F7gaIxAQfKlFDbmNoGOw8lf9qfn 9XbVZVzatK/z3JB9hfc/Ti07nwER7RiAWlYz7nlfDIMAvg839046Tk+d3ZI7YtArVbW0ZHqvy+gW OaFHu5QFcl2Xm/7tFjoaR+EIx+hNl7Ve0OG11enPuS7K3ouQ68tH7eXbYEqxAwohEQSBEEEQbfON g46wo2E8jAdRHgfRcJAPw/goyqMwuo1GPKdRtuU94ktwTemyVnaFM10ZlVEt3Tk1LWJyicmlO8xj sY74SqooyFo6ADdHFv62AdPHhar5ppzLFcYH7tcQYfe5+SS5SXzqGXGaeJ95/AEyf0cLZW5kc3Ry ZWFtCmVuZG9iago4OCAwIG9iago2MTAKZW5kb2JqCjkyIDAgb2JqCjw8L0xlbmd0aCA5MyAwIFIv RmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nKWV32/aMBDH3/NXnPpSkNJAAiVlmiYFSje6 8mM0mjS1fXCTC6QDmzoOjP9+Z4e2tA0TWp2HoIt9d5+775lHqDsu1PWzfUcLqzbxYZpZdZhaj5Zr PsL2FS2gE9KGM3A9CBOrOOOC1wDfP4NwYVX6XKHkqE7OJUsUAHQ7own0eCTilE9BJHDOFIOBiHGO MaxTNYNfwfAr7RyKFS7uUYJXd0+r4YPVaEN4ZVVOHYB+MAygK3iWxiiZSulX9djyWmYDnQ1HcD5y yFRp0e4JJiiRR5gVFtfR3uWCDq7wzVc6fDO56Hqu274D6EgWc5Q2XDs2HH3HDayFjDNIhIQ8Q0g5 0OYMlIA+j9OIKSQnbuMpj501wcc8lbhAruAKVzjPjmzodMfgNm3tBHRIe5vCzjof9anejus3z/za NjMbBkxGM3Dbbb/kyOeZUstPtdp6vXZkEp1gnCohHSGntZQnokY27eWL86pmGrtV9+oa+0HI3/Oc xxSIwHuxpjdtOYFgp2O6hVeMT3M2RV2TfexqhjBERbX7rbuWpNO86BqMpVAiEnO4rQx7YXc0vLit HhX10LkcUA+zDUaRElutlB06oCLaT0lF/HrTCEHLhXMbug4wHsPYgW8iSchGlSGkKCU1dFLO5AZG 9w8Yqf06WErMSAVFAW4reiKeoXU4+x2jsb6n2oFu2Icwaj9ljO7pVuwbG8LnhofUtUu2YteRTJdq i0WD85z55fVoeFs1ethHa+Y/mpFGEC7MyD2BUswSUGM14n6PS5jNwzDJyy5my/H0nUFf/znzvuc1 3ov/KCgupBfVm+k3YAmL9s77gHGaCj3uT8TkvoTYWAdsU+D9l3S1j7K2er5/OM/4VcZ71WtAfL8M RFsvc44fIvH9MpKGa0hSlGbigmIIB84uXDnYPpDrTaZwUdIlClUCZ6xBPs0z9RFhkptdvCBXMyGz YwjimC6FzMjRbRb5/sR0Pkel0AZUwObOS8DenyX9lWRGNjQvFL8Fb9fNWF/K7tkdueyF1g96/gLS 1QusZW5kc3RyZWFtCmVuZG9iago5MyAwIG9iago3NzIKZW5kb2JqCjk3IDAgb2JqCjw8L0xlbmd0 aCA5OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHWTzVbbMBCF936KWbVwCI5/ YsfOihDSFAoUEpdzekoXij04KrIEspyQt+/YsWmhqbyQ7bkafVczegbHdsGpn3ZOC6s/H0JeWg7k 1rPlNkFop7SA04QEEbgeJA/Wbo0Lng/DYQRJYR2cS4Naojk+0+zBAMDk9OscpjJVGZc5qAc4Y4bB lcpQYAYbblbwfXw9I+W1WmOxRA2e4waHyS/LjyG5tA4odMXTFQq4Qy4EGoNwf4AZN0rfHx5+tFy/ 0yWaBJxJA9doNko/lnAuU5s0dTQkG/MKIavgsnqhvVSl8zY200wutz24rXCJKcCFdwHenddGJ0yy jNGHF3Zb3ayUxBEcuYPA8YeBEwThG5RpwbgYQdGQ2+uO/MR0iJzAUlXQoj8+xwJfmMzoDG5QqPX/ bI7TR8FVy+btPCEIBpMVHS7PJWrGsWPHslTyeIHrOtCDU42G0RuAHwSu06o+kf8U9zr0fS+OXW/o OIN9DtkJIxy74fnLyXLFJVvDQhVMs1/V+zJlSvIUZsXyM3yAiYIvsw6EaeqBnJUlArXB7ueZ0nLJ tezBndJMi1pB9YyCDn9clXSw+ys08MNwEDlR7IVuGO+1sIO1yxa2LlID+E+B5lSdLSQVtbh+k+mS Arw8mm11S+Q7NKhxhYCJRnyE8bqryKLi1MKu8wovnlaMqmJYD2bjZqnXdd63xV5PR244jLwgcr3Y 2+dI15y2aThPRMOWb3Vrp8k7Px/RtDLmadTvbzYb+42qXycNdtu+3roeoAEmbHgd05cnrrGEK7aF uFdf3BDejx83LCe38U9KOU2sW3p+A/qSMU1lbmRzdHJlYW0KZW5kb2JqCjk4IDAgb2JqCjYxNQpl bmRvYmoKMTAyIDAgb2JqCjw8L0xlbmd0aCAxMDMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJxdUU1z2jAQvetXvJkeClMw/sIfnAKEdjLTEAJuOpmSg2oL240tJbaI63+fJbHTodrD Svue9r2VnmEaFsxTdDku2WTrI62ZiZQ9M+sNRJfiEouICAEsG9GBvd+xYDvw/QBRyQZXUotKCj2+ rPhBA1gubrZYyVgluUyhDrjkmuNaJaIQCZpcZ7ifr78Rc61eRPlbVLBNazqM/jAnRPSdDQiay6TF IhdVyeXwM7OcHrg/lvynqh5rqp7OXjDFUsVZxSV22uiqu2OuBT5ZntkX8jLHHS8K0Y6wnAOhY3rT Dvyxo43t9RKrkufFDJwsXLQk15zkjFiVxPrncCNobryQbEJ5p9Xjmc+lkvWx0Fzqs96bTEkxwxfH Gruh7fqu5zvYD9ZCZ6IqSLLeD0cEO+PQ8+hVbDcg+CtNF4v98Eyhsxn3QnF7QW7ITE1eDFWl/XTb qxmlTOun2WTSNI1xTpsQz/WCt7Z3Iqcn0lqMIDR4YeBjrf4+5ZWocc1bhKPTl3n4f/3a8FQQ9EAt VxG7pXgFafekZGVuZHN0cmVhbQplbmRvYmoKMTAzIDAgb2JqCjQwMwplbmRvYmoKNCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOSAwIFIKL0ZvbnQg MTAgMCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0IDAgUgovRm9udCAxNSAwIFIKPj4K L0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKMTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE5IDAgUgovRm9udCAyMCAwIFIKPj4KL0NvbnRlbnRz IDE3IDAgUgo+PgplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1 IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRXh0R1N0YXRlIDI0IDAgUgovRm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIyIDAgUgo+ PgplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jv dGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDI5IDAgUgovRm9udCAzMCAwIFIKPj4KL0NvbnRlbnRzIDI3IDAgUgo+PgplbmRvYmoK MzEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM0 IDAgUgovRm9udCAzNSAwIFIKPj4KL0NvbnRlbnRzIDMyIDAgUgo+PgplbmRvYmoKMzYgMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM5IDAgUgovRm9u dCA0MCAwIFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+PgplbmRvYmoKNDEgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ0IDAgUgovRm9udCA0NSAwIFIK Pj4KL0NvbnRlbnRzIDQyIDAgUgo+PgplbmRvYmoKNDYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJv Y1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDQ5IDAgUgovRm9udCA1MCAwIFIKPj4KL0NvbnRl bnRzIDQ3IDAgUgo+PgplbmRvYmoKNTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRXh0R1N0YXRlIDU0IDAgUgovRm9udCA1NSAwIFIKPj4KL0NvbnRlbnRzIDUyIDAg Ugo+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0K L1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov RXh0R1N0YXRlIDU5IDAgUgovRm9udCA2MCAwIFIKPj4KL0NvbnRlbnRzIDU3IDAgUgo+PgplbmRv YmoKNjEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDY0IDAgUgovRm9udCA2NSAwIFIKPj4KL0NvbnRlbnRzIDYyIDAgUgo+PgplbmRvYmoKNjYgMCBv YmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDY5IDAgUgov Rm9udCA3MCAwIFIKPj4KL0NvbnRlbnRzIDY3IDAgUgo+PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVz b3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc0IDAgUgovRm9udCA3NSAw IFIKPj4KL0NvbnRlbnRzIDcyIDAgUgo+PgplbmRvYmoKNzYgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDc5IDAgUgovRm9udCA4MCAwIFIKPj4KL0Nv bnRlbnRzIDc3IDAgUgo+PgplbmRvYmoKODEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFsw IDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsv UERGIC9UZXh0XQovRXh0R1N0YXRlIDg0IDAgUgovRm9udCA4NSAwIFIKPj4KL0NvbnRlbnRzIDgy IDAgUgo+PgplbmRvYmoKODYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0 XQovRXh0R1N0YXRlIDg5IDAgUgovRm9udCA5MCAwIFIKPj4KL0NvbnRlbnRzIDg3IDAgUgo+Pgpl bmRvYmoKOTEgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0 ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0 YXRlIDk0IDAgUgovRm9udCA5NSAwIFIKPj4KL0NvbnRlbnRzIDkyIDAgUgo+PgplbmRvYmoKOTYg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk5IDAg UgovRm9udCAxMDAgMCBSCj4+Ci9Db250ZW50cyA5NyAwIFIKPj4KZW5kb2JqCjEwMSAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA0IDAgUgovRm9u dCAxMDUgMCBSCj4+Ci9Db250ZW50cyAxMDIgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBl IC9QYWdlcyAvS2lkcyBbCjQgMCBSCjExIDAgUgoxNiAwIFIKMjEgMCBSCjI2IDAgUgozMSAwIFIK MzYgMCBSCjQxIDAgUgo0NiAwIFIKNTEgMCBSCjU2IDAgUgo2MSAwIFIKNjYgMCBSCjcxIDAgUgo3 NiAwIFIKODEgMCBSCjg2IDAgUgo5MSAwIFIKOTYgMCBSCjEwMSAwIFIKXSAvQ291bnQgMjAKPj4K ZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDEw NiAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoK OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agoxNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iagoxOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyMCAwIG9iago8PC9SOAo4IDAgUj4+ CmVuZG9iagoyNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SOAo4IDAg Uj4+CmVuZG9iagoyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozMCAwIG9iago8PC9SOAo4 IDAgUj4+CmVuZG9iagozNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozNSAwIG9iago8PC9S OAo4IDAgUj4+CmVuZG9iagozOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0MCAwIG9iago8 PC9SOAo4IDAgUj4+CmVuZG9iago0NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NSAwIG9i ago8PC9SOAo4IDAgUj4+CmVuZG9iago0OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MCAw IG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago1NCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1 NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9i ago2MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago2NCAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iago2NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago2OSAwIG9iago8PC9SNwo3IDAgUj4+ CmVuZG9iago3MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3NCAwIG9iago8PC9SNwo3IDAg Uj4+CmVuZG9iago3NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago3OSAwIG9iago8PC9SNwo3 IDAgUj4+CmVuZG9iago4MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4NCAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iago4NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4OSAwIG9iago8 PC9SNwo3IDAgUj4+CmVuZG9iago5MCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5NCAwIG9i ago8PC9SNwo3IDAgUj4+CmVuZG9iago5NSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago5OSAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMDAgMCBvYmoKPDwvUjgKOCAwIFI+PgplbmRvYmoK MTA0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwNSAwIG9iago8PC9SOAo4IDAgUj4+CmVu ZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0NvdXJpZXIvVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Pj4KZW5kb2JqCjEwNiAwIG9iago8PC9UeXBlL01ldGFkYXRhCi9TdWJ0eXBlL1hNTC9MZW5ndGgg MTM1ND4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5U Y3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1s bnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFt ZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAy LzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAv Jz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MzE4ZTM2YzctYmNjNS0xMWYwLTAw MDAtYjk2NDIzNzk4ZjQ1JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8n IHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0IDkuMDYnLz4KPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9J3V1aWQ6MzE4ZTM2YzctYmNjNS0xMWYwLTAwMDAtYjk2NDIzNzk4ZjQ1JyB4bWxu czp4bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDE1 LTExLTA2VDA5OjA1OjU2LTA4OjAwPC94bXA6TW9kaWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIw MTUtMTEtMDZUMDk6MDU6NTYtMDg6MDA8L3htcDpDcmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29s PkdOVSBFbnNjcmlwdCAxLjYuNS45MDwveG1wOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9u Pgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDozMThlMzZjNy1iY2M1LTExZjAtMDAw MC1iOTY0MjM3OThmNDUnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv bW0vJyB4YXBNTTpEb2N1bWVudElEPSd1dWlkOjMxOGUzNmM3LWJjYzUtMTFmMC0wMDAwLWI5NjQy Mzc5OGY0NScvPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDozMThlMzZjNy1iY2M1 LTExZjAtMDAwMC1iOTY0MjM3OThmNDUnIHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxl bWVudHMvMS4xLycgZGM6Zm9ybWF0PSdhcHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48cmRmOkFs dD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkVuc2NyaXB0IE91dHB1dDwvcmRmOmxpPjwv cmRmOkFsdD48L2RjOnRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8L3JkZjpSREY+CjwveDp4bXBt ZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9J3cnPz4K ZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA5LjA2 KQovQ3JlYXRpb25EYXRlKEQ6MjAxNTExMDYwOTA1NTYtMDgnMDAnKQovTW9kRGF0ZShEOjIwMTUx MTA2MDkwNTU2LTA4JzAwJykKL1RpdGxlKEVuc2NyaXB0IE91dHB1dCkKL0NyZWF0b3IoR05VIEVu c2NyaXB0IDEuNi41LjkwKT4+ZW5kb2JqCnhyZWYKMCAxMDcKMDAwMDAwMDAwMCA2NTUzNSBmIAow MDAwMDE5MTU5IDAwMDAwIG4gCjAwMDAwMjE5NjIgMDAwMDAgbiAKMDAwMDAxODk2NSAwMDAwMCBu IAowMDAwMDE1NzIzIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMTA0OCAwMDAw MCBuIAowMDAwMDE5MjI1IDAwMDAwIG4gCjAwMDAwMjA0NjggMDAwMDAgbiAKMDAwMDAxOTI2NiAw MDAwMCBuIAowMDAwMDE5Mjk1IDAwMDAwIG4gCjAwMDAwMTU4ODIgMDAwMDAgbiAKMDAwMDAwMTA2 NyAwMDAwMCBuIAowMDAwMDAyMDc4IDAwMDAwIG4gCjAwMDAwMTkzMjUgMDAwMDAgbiAKMDAwMDAx OTM1NSAwMDAwMCBuIAowMDAwMDE2MDQ0IDAwMDAwIG4gCjAwMDAwMDIwOTggMDAwMDAgbiAKMDAw MDAwMjk3MSAwMDAwMCBuIAowMDAwMDE5Mzg1IDAwMDAwIG4gCjAwMDAwMTk0MTUgMDAwMDAgbiAK MDAwMDAxNjIwNiAwMDAwMCBuIAowMDAwMDAyOTkxIDAwMDAwIG4gCjAwMDAwMDQwNjIgMDAwMDAg biAKMDAwMDAxOTQ0NSAwMDAwMCBuIAowMDAwMDE5NDc1IDAwMDAwIG4gCjAwMDAwMTYzNjggMDAw MDAgbiAKMDAwMDAwNDA4MiAwMDAwMCBuIAowMDAwMDA0ODU3IDAwMDAwIG4gCjAwMDAwMTk1MDUg MDAwMDAgbiAKMDAwMDAxOTUzNSAwMDAwMCBuIAowMDAwMDE2NTMwIDAwMDAwIG4gCjAwMDAwMDQ4 NzcgMDAwMDAgbiAKMDAwMDAwNTUxOSAwMDAwMCBuIAowMDAwMDE5NTY1IDAwMDAwIG4gCjAwMDAw MTk1OTUgMDAwMDAgbiAKMDAwMDAxNjY5MiAwMDAwMCBuIAowMDAwMDA1NTM5IDAwMDAwIG4gCjAw MDAwMDYyMjUgMDAwMDAgbiAKMDAwMDAxOTYyNSAwMDAwMCBuIAowMDAwMDE5NjU1IDAwMDAwIG4g CjAwMDAwMTY4NTQgMDAwMDAgbiAKMDAwMDAwNjI0NSAwMDAwMCBuIAowMDAwMDA2OTMyIDAwMDAw IG4gCjAwMDAwMTk2ODUgMDAwMDAgbiAKMDAwMDAxOTcxNSAwMDAwMCBuIAowMDAwMDE3MDE2IDAw MDAwIG4gCjAwMDAwMDY5NTIgMDAwMDAgbiAKMDAwMDAwNzgyMyAwMDAwMCBuIAowMDAwMDE5NzQ1 IDAwMDAwIG4gCjAwMDAwMTk3NzUgMDAwMDAgbiAKMDAwMDAxNzE3OCAwMDAwMCBuIAowMDAwMDA3 ODQzIDAwMDAwIG4gCjAwMDAwMDg2MzAgMDAwMDAgbiAKMDAwMDAxOTgwNSAwMDAwMCBuIAowMDAw MDE5ODM1IDAwMDAwIG4gCjAwMDAwMTczNDAgMDAwMDAgbiAKMDAwMDAwODY1MCAwMDAwMCBuIAow MDAwMDA5MjM3IDAwMDAwIG4gCjAwMDAwMTk4NjUgMDAwMDAgbiAKMDAwMDAxOTg5NSAwMDAwMCBu IAowMDAwMDE3NTAyIDAwMDAwIG4gCjAwMDAwMDkyNTcgMDAwMDAgbiAKMDAwMDAxMDAyNCAwMDAw MCBuIAowMDAwMDE5OTI1IDAwMDAwIG4gCjAwMDAwMTk5NTUgMDAwMDAgbiAKMDAwMDAxNzY2NCAw MDAwMCBuIAowMDAwMDEwMDQ0IDAwMDAwIG4gCjAwMDAwMTA3ODcgMDAwMDAgbiAKMDAwMDAxOTk4 NSAwMDAwMCBuIAowMDAwMDIwMDE1IDAwMDAwIG4gCjAwMDAwMTc4MjYgMDAwMDAgbiAKMDAwMDAx MDgwNyAwMDAwMCBuIAowMDAwMDExNjM1IDAwMDAwIG4gCjAwMDAwMjAwNDUgMDAwMDAgbiAKMDAw MDAyMDA3NSAwMDAwMCBuIAowMDAwMDE3OTg4IDAwMDAwIG4gCjAwMDAwMTE2NTUgMDAwMDAgbiAK MDAwMDAxMjI3OCAwMDAwMCBuIAowMDAwMDIwMTA1IDAwMDAwIG4gCjAwMDAwMjAxMzUgMDAwMDAg biAKMDAwMDAxODE1MCAwMDAwMCBuIAowMDAwMDEyMjk4IDAwMDAwIG4gCjAwMDAwMTI5MzIgMDAw MDAgbiAKMDAwMDAyMDE2NSAwMDAwMCBuIAowMDAwMDIwMTk1IDAwMDAwIG4gCjAwMDAwMTgzMTIg MDAwMDAgbiAKMDAwMDAxMjk1MiAwMDAwMCBuIAowMDAwMDEzNjM0IDAwMDAwIG4gCjAwMDAwMjAy MjUgMDAwMDAgbiAKMDAwMDAyMDI1NSAwMDAwMCBuIAowMDAwMDE4NDc0IDAwMDAwIG4gCjAwMDAw MTM2NTQgMDAwMDAgbiAKMDAwMDAxNDQ5OCAwMDAwMCBuIAowMDAwMDIwMjg1IDAwMDAwIG4gCjAw MDAwMjAzMTUgMDAwMDAgbiAKMDAwMDAxODYzNiAwMDAwMCBuIAowMDAwMDE0NTE4IDAwMDAwIG4g CjAwMDAwMTUyMDUgMDAwMDAgbiAKMDAwMDAyMDM0NSAwMDAwMCBuIAowMDAwMDIwMzc1IDAwMDAw IG4gCjAwMDAwMTg3OTkgMDAwMDAgbiAKMDAwMDAxNTIyNSAwMDAwMCBuIAowMDAwMDE1NzAyIDAw MDAwIG4gCjAwMDAwMjA0MDYgMDAwMDAgbiAKMDAwMDAyMDQzNyAwMDAwMCBuIAowMDAwMDIwNTMw IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTA3IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9J RCBbPEM4ODdBMTM3MTI1NjlEMUZGMjBCOEE3NUU0RjU2NzZGPjxDODg3QTEzNzEyNTY5RDFGRjIw QjhBNzVFNEY1Njc2Rj5dCj4+CnN0YXJ0eHJlZgoyMjE0MQolJUVPRgo= --_003_BLUPR06MB1763F35D73A9ED9A451915BDFE1D0BLUPR06MB1763namp_-- From nobody Tue Nov 17 11:21:01 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53531A6FB0 for ; Tue, 17 Nov 2015 11:20:59 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXTYUj2vsiDF for ; Tue, 17 Nov 2015 11:20:57 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F4B1A6FAE for ; Tue, 17 Nov 2015 11:20:57 -0800 (PST) Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB274.namprd06.prod.outlook.com (10.141.22.150) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 19:20:55 +0000 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.325.17; Tue, 17 Nov 2015 19:20: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.0325.003; Tue, 17 Nov 2015 19:20:53 +0000 From: Michel Veillette To: Rodney Cummings , peter van der Stok , Core Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbWsbLKAGX5UGJtJafdAsAuZ6gXYKAgAAAvXA= Date: Tue, 17 Nov 2015 19:20:53 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:1q2MNjortydwGmu2J4L4dvI076cT7naM4Lvul91tCzvhItrZ+0cVwT9aK3j5dtBpl5cNGshitjHv8GzynlG2Wi+DKKBJt507Ra3I6p/gQr8Phv5WmLAMZjAUdAv/Lajggjc6LjkrJAw5gKQw6Y42vQ==; 24:QpkreAQk3E7XRHyj7K2L1gzaqyNfzE4ZeRU9sfd63w56E0EH0FKvb5bPfUesKmw93FSM9zJH+d7qSWoo6hjXJ0vMz88h4B4iB57XIEfDGNc=; 20:H8SrgKZkhJc8cSHT99q2UJ5n2RVfXTEOyIW8274p2h0O9LrhWnvQ+SIk5Is9wemC2jIZDhA8HLvGUhIvBVmcgQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027)(262738631018165); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(38414003)(189002)(377454003)(54094003)(13464003)(53754006)(106116001)(81156007)(87936001)(19580405001)(122556002)(11100500001)(5008740100001)(76176999)(15974865002)(586003)(106356001)(19580395003)(102836002)(50986999)(5001770100001)(92566002)(105586002)(76576001)(74316001)(99286002)(15975445007)(5001960100002)(5001920100001)(54356999)(40100003)(2900100001)(101416001)(10400500002)(86362001)(2950100001)(33656002)(5004730100002)(66066001)(5002640100001)(189998001)(97736004)(5003600100002)(5007970100001)(77096005)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 19:20:53.6212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-Microsoft-Exchange-Diagnostics: 1; BLUPR06MB274; 2:DGPG9+WzgouYAQUAJ4kABtfMo1Uea+g2/56pdmHGo2wBy7Fkld3d+YH8Ne3bonXoW3Ku7ZepPEJWMgE11qIMXCEtz7OqGXQ89NKGflsOtxhEkK/NQ/2Anp73YitiXNMJZJLCxVpFa7nASFrq9u8OfQykjl58538lYyZPEOUXQhg=; 23:LjIy0p3mNsq8KjPViuH7vEbdHBrzz8m4CppMRlWQMzfct6O1ieksOfTDW4hEqt+njYu0UoxtNWCziOg+kAssOgCnQb44pr2Zwtb5548nCzXTBPEWlPYa6gdbVGrNjArrp378nZjfCJvXmXjl+6jYUlhSUEtzpIeeH/werJ4p1Ga4NCteOr/Qf7bHgXodSNUy X-OriginatorOrg: trilliantinc.com Archived-At: Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 19:20:59 -0000 Hi Rodney Would you please elaborate your item#2 "A client cannot assume that the YAN= G objects of a module are distinct from a hashing perspective." I'm not sure I fully understand the implications of this statement. The CoOL draft propose to prefix all objects (data nodes, rpc and notificat= ions) defined by a module & associated sub-modules with a common identifier= . What is the impacts of item 2 on this approach? Regards, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com =A0=20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Rodney Cummings Sent: November-17-15 10:52 AM To: peter van der Stok ; Core Subject: Re: [core] CoMI Cool draft splits Thanks Peter, At this time, proceeding with 4 drafts sounds good to me. Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts: a) YANG to CBOR mapping ( i) ) b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that: 1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL. 2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective. 3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset). If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may hel= p to decide between hash/registry. If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale. Rodney -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Tuesday, November 17, 2015 3:41 AM To: Core Subject: [core] CoMI Cool draft splits Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into t= hree parts as suggested by Juergen Schoenwalder in a separate earlier commu= nication. This e_mail sets out in more detail why the proposed split is a good one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and CoM= I. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it may= be advisable to submit the draft to the netmod WG, where much of the YANG = expertise exists and the draft can be aligned with the YANG to JSON draft. Ad ii and iii) These approaches are very different and merit independent dr= afts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.=20 It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and Co= OL, may take some time. I will be happy if in Buenos Aires we have a list w= ith issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org _______________________________________________ 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 Tue Nov 17 13:32:52 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F281A893E for ; Tue, 17 Nov 2015 13:32:50 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MviCN6Nm-xhX for ; Tue, 17 Nov 2015 13:32:47 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.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 B72FE1ABD38 for ; Tue, 17 Nov 2015 13:32:47 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 21:32:45 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) with mapi id 15.01.0325.003; Tue, 17 Nov 2015 21:32:45 +0000 From: Rodney Cummings To: Michel Veillette , peter van der Stok , Core Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwteQFUWYBvd0yDLSdmSQn7rZ6gWGHwgAA/jYCAABjhAA== Date: Tue, 17 Nov 2015 21:32:45 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.33] x-microsoft-exchange-diagnostics: 1; BN1PR04MB424; 5:f8nF85PeO3yvRGCGKmr3Em63xDT05tbl8qFjxjk+7qXGygMp5S3JbHqcCtKXt+YyCZRP6prOvXJMl8y32e+fwSGdfn/wfyJvLZO8OuDqh75f2H4AUmvmFo83UQj6//P7tK53xuD9UJIMJBTpbnJEew==; 24:pP0m8pMKj2UZkbnBuRJLo/+92HJDoUK60SWau71ILOwgDx+LQsHtgsZhdEoJEn+zus7EHWzyXm6Z5J8T0tmyod77OGTT/o+bcW49+mXbioc=; 20:/05PrlLjhS4m8tnDNNe7lOiasaZ4seyV6HhqRtGOfZoa1u0bCE77D9Jmq8bw6Z/viNRGp5IUSp6dQrn2Ly/82g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB424; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027)(144836121648609)(262738631018165)(216554174695431); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN1PR04MB424; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB424; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(199003)(189002)(377424004)(38414003)(54094003)(13464003)(106356001)(87936001)(19580405001)(19580395003)(99286002)(86362001)(106116001)(5001960100002)(189998001)(33656002)(105586002)(97736004)(5001770100001)(81156007)(74316001)(76576001)(10400500002)(586003)(122556002)(92566002)(5004730100002)(5008740100001)(15974865002)(5003600100002)(11100500001)(40100003)(15975445007)(5007970100001)(76176999)(54356999)(2900100001)(2950100001)(50986999)(66066001)(101416001)(5002640100001)(102836002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB424; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 21:32:45.3817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB424 Archived-At: Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 21:32:51 -0000 Thanks Michel, To back up a bit, I think I may be misunderstanding a fundamental assumptio= n in the design of both CoMI and CoOL. Please forgive my ignorance. Of my three points, I think the fundamental point is #3, and #1 and #2 are = just symptoms. To elaborate on #3 with an example, let's say I have a modul= e "foo", with two revisions: - 2011-01-09: original - 2015-08-07: enhanced Both CoMI and CoOL seem to be designed under the assumption that the origin= al revision is a proper subset of the enhanced revision (i.e. objects were = added, but none removed).=20 For CoMI, this is why the client must read the ietf-yang-hash module to obt= ain re-hash mapping. The server presumably promises to leave the hashes of = the original unchanged in the enhanced. Therefore, only the server knows th= e re-hash values, which must be queried by the client. For CoOL, the algorithm for the client to find an automatic DNID is clear. = Nevertheless, the manual DNID (YANG "id" extension) is provided so that the= module author can manually ensure that DNIDs of the original remain the sa= me in the enhanced. As I think through this for the client side, I don't think it is valid for = my client to assume that the enhanced is a proper subset of the original (i= tem #3). I realize that a proper subset is common in practice, but it is no= t guaranteed. From my reading of RFC6020bis, the enhanced module can comple= tely remove all objects from original. Therefore, on the client side, it would be easier for me to assume the "aut= omatic" implementation in the server.=20 In the context of Cool, "automatic" means the automatic DNID algorithm. I w= ould prefer to avoid the "manual" mechanism entirely (my item #1). Rather t= han create CoOL-specific YANG modules, just force the client to process the= normal YANG module assuming that all DNID are automatic. In the context for CoMI, specify an "automatic" algorithm for resolving has= h collisions, similar to CoOL's automatic DNID. This enables a client and s= erver to use the same re-hash, and it avoids the need to query the ietf-yan= g-hash module. Overall, it seems like the most challenging aspects of CoMI and CoOL are th= e "manual" extensions to help with backward compatibility (item #3). To a n= aive reader such as myself, these "manual" extensions make the draft far mo= re complex, and it would be simpler to use the "automatic" technique in bot= h client and server. Rodney -----Original Message----- From: Michel Veillette [mailto:Michel.Veillette@trilliantinc.com]=20 Sent: Tuesday, November 17, 2015 1:21 PM To: Rodney Cummings ; peter van der Stok ; Core Cc: Somaraju Abhinav ; Turner, Randy ; Alexander Pelov Subject: RE: [core] CoMI Cool draft splits Hi Rodney Would you please elaborate your item#2 "A client cannot assume that the YAN= G objects of a module are distinct from a hashing perspective." I'm not sure I fully understand the implications of this statement. The CoOL draft propose to prefix all objects (data nodes, rpc and notificat= ions) defined by a module & associated sub-modules with a common identifier= . What is the impacts of item 2 on this approach? Regards, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com =A0=20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Rodney Cummings Sent: November-17-15 10:52 AM To: peter van der Stok ; Core Subject: Re: [core] CoMI Cool draft splits Thanks Peter, At this time, proceeding with 4 drafts sounds good to me. Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts: a) YANG to CBOR mapping ( i) ) b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that: 1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL. 2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective. 3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset). If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may hel= p to decide between hash/registry. If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale. Rodney -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Tuesday, November 17, 2015 3:41 AM To: Core Subject: [core] CoMI Cool draft splits Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into t= hree parts as suggested by Juergen Schoenwalder in a separate earlier commu= nication. This e_mail sets out in more detail why the proposed split is a good one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and CoM= I. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it may= be advisable to submit the draft to the netmod WG, where much of the YANG = expertise exists and the draft can be aligned with the YANG to JSON draft. Ad ii and iii) These approaches are very different and merit independent dr= afts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.=20 It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and Co= OL, may take some time. I will be happy if in Buenos Aires we have a list w= ith issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org _______________________________________________ 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 Tue Nov 17 14:26:42 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB401B341A for ; Tue, 17 Nov 2015 14:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyU6YfuS5_7V for ; Tue, 17 Nov 2015 14:26:33 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373EB1B3419 for ; Tue, 17 Nov 2015 14:26:33 -0800 (PST) Received: by lbbsy6 with SMTP id sy6so14201357lbb.2 for ; Tue, 17 Nov 2015 14:26:31 -0800 (PST) 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:content-type; bh=4fvKRtHyl/ksLutJHCi/ZV5rsYKtE1IaXw70YQmE0eI=; b=vX2ngp2j6JS68MEpg4u19pFhT+EjmOTFFAhdaOFdSVo1EggfVWLHr0sSLf2Tu15plv jCLe1EY1noehJYC3nqmn2sQKqcueg2ztuLhpmyQ5tPevKchqc7dW1NAEqh8Pr9lsC3Cw +QMumUPJ6h3cbvQUNRGI8OkdiEDBID16RNdd5G6evjuxzAodjv/78ERrf0MkA6qcmhln 41Z5hbQQLhJSOZJQGYzEGADeIq3GQOrWAWV4KRtl5S3Ptng/6LUqcdDKQOVh/r0KLfNT /QEMLjdM9CxV+w9tz+asNaGbSEEXz3c1pNPXjO0K8yoX6VJ2wACst9RyaBaNNEQB4+rX haLQ== 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:content-type; bh=4fvKRtHyl/ksLutJHCi/ZV5rsYKtE1IaXw70YQmE0eI=; b=U/kauMafutbqttixfF78B9V+1NRuNfGubgq9S7tqrv8xOKbvHFQOXi8vkc8l9oK6V5 NyZ+vLGB8FG8ISBM6oqzjWXP2LoqGGhO9JTrQ420bqXduifbvCo3AfKtuAnKS6BnxHOf FWk7fhlJwgxfwix9Iebi/6NS9fd3iO+1P/4Lw2eCnI3ViCZdSKIKKWu7SegsWLQZGhvv 54wR916ol/jq9jcajcrSeFCPSMV//MPOku5TF+ivrkggSj6UZKZnUgo+xi8k5O5/Dzap ltGhokqa7sLkH+JrunSM92GsjKqOIPsG5yZGX9/uHCXre0IiVFWxC2ImKxBaZeKAfsIc 0FBw== X-Gm-Message-State: ALoCoQlaESRxrcg58/sW5AssYGGKP7AOqu6h/7+lm35euFrv9Icpmq7vyGygtW8tY4ty9lEh/uma MIME-Version: 1.0 X-Received: by 10.112.157.166 with SMTP id wn6mr18369925lbb.30.1447799191314; Tue, 17 Nov 2015 14:26:31 -0800 (PST) Received: by 10.112.144.106 with HTTP; Tue, 17 Nov 2015 14:26:31 -0800 (PST) In-Reply-To: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Date: Tue, 17 Nov 2015 14:26:31 -0800 Message-ID: From: Andy Bierman To: Rodney Cummings Content-Type: multipart/alternative; boundary=001a11c264168145b20524c40498 Archived-At: Cc: peter van der Stok , Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:26:37 -0000 --001a11c264168145b20524c40498 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 17, 2015 at 1:32 PM, Rodney Cummings wrote: > Thanks Michel, > > To back up a bit, I think I may be misunderstanding a fundamental > assumption in the design of both CoMI and CoOL. Please forgive my ignorance. > > Of my three points, I think the fundamental point is #3, and #1 and #2 are > just symptoms. To elaborate on #3 with an example, let's say I have a > module "foo", with two revisions: > - 2011-01-09: original > - 2015-08-07: enhanced > > Both CoMI and CoOL seem to be designed under the assumption that the > original revision is a proper subset of the enhanced revision (i.e. objects > were added, but none removed). > > YANG does not actually allow objects to be removed. The status is allowed to change to "obsolete". YANG hash and automatic numbering will both be able to "remember" the deleted object IDs so they can never be reused. The "automatic" numbering only works for the first version of a module. Manual numbering will almost certainly be required after that. The YANG extensions for numbering are confusing to me. Why would I want to hard-wire the numbers to start at N? How does this fix the "uses from an expanded grouping" problem I mentioned before, that changes the automatic number assignments? > For CoMI, this is why the client must read the ietf-yang-hash module to > obtain re-hash mapping. The server presumably promises to leave the hashes > of the original unchanged in the enhanced. Therefore, only the server knows > the re-hash values, which must be queried by the client. > I agree that the client needs to be able to handle future rehashes in order to work. A new server revision can have a clash for an object that did not clash in the previous version. This code is rather simple and also generic. The code to read the rehash and replace the bad hashes with the rehashes does not need to know any data-model specific info to work. I am quite concerned about the comment that was made in the meeting that there will be some modules that never get registered. The entire premise of CooL is that every module MUST and therefore will get registered. Andy > > For CoOL, the algorithm for the client to find an automatic DNID is clear. > Nevertheless, the manual DNID (YANG "id" extension) is provided so that the > module author can manually ensure that DNIDs of the original remain the > same in the enhanced. > > As I think through this for the client side, I don't think it is valid for > my client to assume that the enhanced is a proper subset of the original > (item #3). I realize that a proper subset is common in practice, but it is > not guaranteed. From my reading of RFC6020bis, the enhanced module can > completely remove all objects from original. > > Therefore, on the client side, it would be easier for me to assume the > "automatic" implementation in the server. > > In the context of Cool, "automatic" means the automatic DNID algorithm. I > would prefer to avoid the "manual" mechanism entirely (my item #1). Rather > than create CoOL-specific YANG modules, just force the client to process > the normal YANG module assuming that all DNID are automatic. > > In the context for CoMI, specify an "automatic" algorithm for resolving > hash collisions, similar to CoOL's automatic DNID. This enables a client > and server to use the same re-hash, and it avoids the need to query the > ietf-yang-hash module. > > Overall, it seems like the most challenging aspects of CoMI and CoOL are > the "manual" extensions to help with backward compatibility (item #3). To a > naive reader such as myself, these "manual" extensions make the draft far > more complex, and it would be simpler to use the "automatic" technique in > both client and server. > > Rodney > > > -----Original Message----- > From: Michel Veillette [mailto:Michel.Veillette@trilliantinc.com] > Sent: Tuesday, November 17, 2015 1:21 PM > To: Rodney Cummings ; peter van der Stok < > stokcons@xs4all.nl>; Core > Cc: Somaraju Abhinav ; Turner, Randy < > Randy.Turner@landisgyr.com>; Alexander Pelov < > alexander.pelov@telecom-bretagne.eu> > Subject: RE: [core] CoMI Cool draft splits > > Hi Rodney > > Would you please elaborate your item#2 "A client cannot assume that the > YANG objects of a module are distinct from a hashing perspective." > I'm not sure I fully understand the implications of this statement. > > The CoOL draft propose to prefix all objects (data nodes, rpc and > notifications) defined by a module & associated sub-modules with a common > identifier. What is the impacts of item 2 on this approach? > > Regards, > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com > > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Rodney Cummings > Sent: November-17-15 10:52 AM > To: peter van der Stok ; Core > Subject: Re: [core] CoMI Cool draft splits > > Thanks Peter, > > At this time, proceeding with 4 drafts sounds good to me. > > Nevertheless, as we get closer to progressing these in a WG, I think we > should transition to 2 drafts: > a) YANG to CBOR mapping ( i) ) > b) Select either hash ( ii) ) or registry ( iii) ), and merge that with > the function set ( iv) ) for a single draft > > As for the motivation and use cases, I wonder if it might be helpful to > state our assumptions for the client side. I would claim that: > 1. A client cannot assume that the YANG modules implemented by the server > have been enhanced specifically for CoMI/CoOL. > 2. A client cannot assume that the YANG objects of a module are distinct > from a hashing perspective. > 3. A client cannot assume that a new revision of a module is backward > compatible to an older revision of that module (i.e. old is proper subset). > If these assumptions are correct, then the client must perform some > processing of the server's YANG modules prior to using CoMI/CoOL, and that > may help to decide between hash/registry. > If these assumptions are incorrect, it might be useful to discuss it in > the draft, to provide some background rationale. > > Rodney > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok > Sent: Tuesday, November 17, 2015 3:41 AM > To: Core > Subject: [core] CoMI Cool draft splits > > Hi all, > > During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into > three parts as suggested by Juergen Schoenwalder in a separate earlier > communication. > This e_mail sets out in more detail why the proposed split is a good one. > > The proposed three parts are: > 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) > 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) > 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) > > The split has two advantages: > - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF > - It separates out the issues which need to be solved to merge CoOL and > CoMI. > > I come to the generation of 4 drafts: > i) The YANG to CBOR mapping. > ii) Hashing of YANG names > iii) Managed identifier assignment to YANG names > iv) The Function set specification > > Ad i) I don't expect a long list of issues for the merging. However, it > may be advisable to submit the draft to the netmod WG, where much of the > YANG expertise exists and the draft can be aligned with the YANG to JSON > draft. > Ad ii and iii) These approaches are very different and merit independent > drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts. > It is also possible that drafts get submitted to other WGs. > Ad iv) In my view the alignment of the two existing approaches, CoMI and > CoOL, may take some time. I will be happy if in Buenos Aires we have a list > with issues, accompanying motivation, and use cases. > > Is this a valid approach? Comments are solicited. > > Peter > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11c264168145b20524c40498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 17, 2015 at 1:32 PM, Rodney Cummings <= rodney.cummings= @ni.com> wrote:
Thanks Mich= el,

To back up a bit, I think I may be misunderstanding a fundamental assumptio= n in the design of both CoMI and CoOL. Please forgive my ignorance.

Of my three points, I think the fundamental point is #3, and #1 and #2 are = just symptoms. To elaborate on #3 with an example, let's say I have a m= odule "foo", with two revisions:
- 2011-01-09: original
- 2015-08-07: enhanced

Both CoMI and CoOL seem to be designed under the assumption that the origin= al revision is a proper subset of the enhanced revision (i.e. objects were = added, but none removed).


YANG does not actually allow objects t= o be removed.
The status is allowed to change to "obsolete&q= uot;.
YANG hash and automatic numbering will both be able
to "remember" the deleted object IDs so they can never be reus= ed.

The "automatic" numbering only works= for the first version of a module.
Manual numbering will almost = certainly be required after that.
The YANG extensions for numberi= ng are confusing to me.
Why would I want to hard-wire the numbers= to start at N?
How does this fix the "uses from an expanded= grouping" problem
I mentioned before, that changes the = automatic number assignments?



<= /div>
=C2=A0
For CoMI, this is why the client must read the ietf-yang-hash module to obt= ain re-hash mapping. The server presumably promises to leave the hashes of = the original unchanged in the enhanced. Therefore, only the server knows th= e re-hash values, which must be queried by the client.


I agree that the client needs to be able to = handle future rehashes in order
to work.=C2=A0 A new server revis= ion can have a clash for an object that did
not clash in the prev= ious version.=C2=A0 This code is rather simple
and also generic. = The code to read the rehash and replace the bad hashes
with the r= ehashes does not need to know any data-model specific info to work.

I am quite concerned about the comment that was made in t= he meeting that
there will be some modules that never get registe= red.=C2=A0 The entire premise
of CooL is that every module MUST a= nd therefore will get registered.


<= br>
Andy


=C2=A0

For CoOL, the algorithm for the client to find an automatic DNID is clear. = Nevertheless, the manual DNID (YANG "id" extension) is provided s= o that the module author can manually ensure that DNIDs of the original rem= ain the same in the enhanced.

As I think through this for the client side, I don't think it is valid = for my client to assume that the enhanced is a proper subset of the origina= l (item #3). I realize that a proper subset is common in practice, but it i= s not guaranteed. From my reading of RFC6020bis, the enhanced module can co= mpletely remove all objects from original.

Therefore, on the client side, it would be easier for me to assume the &quo= t;automatic" implementation in the server.

In the context of Cool, "automatic" means the automatic DNID algo= rithm. I would prefer to avoid the "manual" mechanism entirely (m= y item #1). Rather than create CoOL-specific YANG modules, just force the c= lient to process the normal YANG module assuming that all DNID are automati= c.

In the context for CoMI, specify an "automatic" algorithm for res= olving hash collisions, similar to CoOL's automatic DNID. This enables = a client and server to use the same re-hash, and it avoids the need to quer= y the ietf-yang-hash module.

Overall, it seems like the most challenging aspects of CoMI and CoOL are th= e "manual" extensions to help with backward compatibility (item #= 3). To a naive reader such as myself, these "manual" extensions m= ake the draft far more complex, and it would be simpler to use the "au= tomatic" technique in both client and server.

Rodney


-----Original Message-----
From: Michel Veillette [mailto:Michel.Veillette@trilliantinc.com]
Sent: Tuesday, November 17, 2015 1:21 PM
To: Rodney Cummings <rodney.cu= mmings@ni.com>; peter van der Stok <stokcons@xs4all.nl>; Core <core@ietf.org>
Cc: Somaraju Abhinav <a= bhinav.somaraju@tridonic.com>; Turner, Randy <Randy.Turner@landisgyr.com>; Alexander Pe= lov <alexander.pe= lov@telecom-bretagne.eu>
Subject: RE: [core] CoMI Cool draft splits

Hi Rodney

Would you please elaborate your item#2 "A client cannot assume that th= e YANG objects of a module are distinct from a hashing perspective." I'm not sure I fully understand the implications of this statement.

The CoOL draft propose to prefix all objects (data nodes, rpc and notificat= ions) defined by a module & associated sub-modules with a common identi= fier. What is the impacts of item 2 on this approach?

Regards,

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
michel.veillette@trill= iantinc.com
www.trilliantinc.com =C2=A0



-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of Rodney Cummings
Sent: November-17-15 10:52 AM
To: peter van der Stok <stokcons@x= s4all.nl>; Core <core@ietf.org>
Subject: Re: [core] CoMI Cool draft splits

Thanks Peter,

At this time, proceeding with 4 drafts sounds good to me.

Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts:
a) YANG to CBOR mapping ( i) )
b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft

As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that:
1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL.
2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective.
3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset).
If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may= help to decide between hash/registry.
If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale.

Rodney

-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of peter van der Stok
Sent: Tuesday, November 17, 2015 3:41 AM
To: Core <core@ietf.org>
Subject: [core] CoMI Cool draft splits

Hi all,

During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into t= hree parts as suggested by Juergen Schoenwalder in a separate earlier commu= nication.
This e_mail sets out in more detail why the proposed split is a good one.
The proposed three parts are:
1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL)
3) The YANG name compression (section 5 in CoMI; section 6 in CoOL)

The split has two advantages:
- the parts 2 and 3 can be used in other contexts, e.g. RESTCONF
- It separates out the issues which need to be solved to merge CoOL and CoM= I.

I come to the generation of 4 drafts:
i) The YANG to CBOR mapping.
ii) Hashing of YANG names
iii) Managed identifier assignment to YANG names
iv) The Function set specification

Ad i) I don't expect a long list of issues for the merging. However, it= may be advisable to submit the draft to the netmod WG, where much of the Y= ANG expertise exists and the draft can be aligned with the YANG to JSON dra= ft.
Ad ii and iii) These approaches are very different and merit independent dr= afts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.
It is also possible that drafts get submitted to other WGs.
Ad iv) In my view the alignment of the two existing approaches, CoMI and Co= OL, may take some time. I will be happy if in Buenos Aires we have a list w= ith issues, accompanying motivation, and use cases.

Is this a valid approach? Comments are solicited.

Peter

--
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vandersto= k.org

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

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

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

--001a11c264168145b20524c40498-- From nobody Tue Nov 17 14:30:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88CC1B3434 for ; Tue, 17 Nov 2015 14:30:23 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjtbKlKXlES4 for ; Tue, 17 Nov 2015 14:30:20 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B236C1B3431 for ; Tue, 17 Nov 2015 14:30:19 -0800 (PST) Received: from BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 22:30:17 +0000 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.325.17; Tue, 17 Nov 2015 22:30:15 +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.0325.003; Tue, 17 Nov 2015 22:30:15 +0000 From: Michel Veillette To: Rodney Cummings Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbWsbLKAGX5UGJtJafdAsAuZ6gXYKAgAAAvXCAAF6HgIAACZNA Date: Tue, 17 Nov 2015 22:30:15 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:1H1DX910l30T9QFoyrw2dZTJ/Q8XheWD66xNQHQyniyILC6Xxwzg2fwWv6KC4UslsCMomFX6Joq9cyToJ1G3T1GxN8gzGvyIX4lbW6dVmPlAZhwOOvrS6fDdaz9w4+FIxvw0EmyZy2IHDoL5rbOhWw==; 24:wCxs4ZK8e2Qfncq2y9vPjQn9ofP1y4y+GPwEH8fk0Q/dNR6Pp8H2p9ee5ONDzlU1UzX85QL91/P3G+qM8y66pPxMMy/s1nsMWlnXTDI/Ncc=; 20:1ti6mjivSXgwRRbnoEzikyoKEPyRZll/uIxubZXuxLntjdeZFjtPHhgnUUF9YIqhMM0Qz8mcWYqGLimB0zJkhQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027)(144836121648609)(262738631018165)(216554174695431); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(199003)(53754006)(38414003)(54094003)(189002)(13464003)(2950100001)(81156007)(97736004)(106116001)(50986999)(106356001)(5007970100001)(5003600100002)(5001960100002)(15975445007)(76176999)(102836002)(586003)(87936001)(40100003)(110136002)(189998001)(101416001)(5004730100002)(122556002)(19580395003)(2900100001)(99286002)(105586002)(10400500002)(66066001)(11100500001)(5008740100001)(15974865002)(92566002)(33656002)(19580405001)(76576001)(77096005)(93886004)(5002640100001)(74316001)(86362001)(54356999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 22:30:15.3192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-Microsoft-Exchange-Diagnostics: 1; BLUPR06MB244; 2:22pvq2QW2QrHOjNMHf12qM29YMtJKP7GfNSmFKqlJ/v9N/u3D1yPEX3JHL2VV5ZGzqe92mOaEU1DjGropoUvKG64D/7+QgKNrK+HAWRzDXindSBwvoQVMADXhUKHTfnz9+NYaM/xmVnMFf7bR5aoFAPriGwcKskiM22ui1CIWOE=; 23:pfyIo5e95ZjeGFc6lVWoNeiHhg+ndH0VDPkTEAC9pBePpPSWcv9V8fp4pNdX59ccHfvDdJon2mnuKxzBmHPT3NRfQpWyDwlD5sZajqaXuIUCxxsckY/ERFJr/XeHEC2CTKQ2lkm4Y/hFjiMzoo8ggiXY1SnUc6AK6C0cSnBCMA3z6wEZvB4DZ/YhRRnhe+mx X-OriginatorOrg: trilliantinc.com Archived-At: Cc: peter van der Stok , Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:30:23 -0000 Hi Rodney If I understand correctly, you propose to automatically generate IDs based = on the YANG definition files of the modules implemented by each CoMI/CoOL = server. Is this correct? If this is the case, I don't things we can assume that the targeted constra= ined networks have enough bandwidth to transfer these files, neither the no= des have enough resources to process these files. CoMI / CoOL server are implemented with a simple map of ID vs. values. On the client side, the right ID need to be used in function of the version= / rehash. The goal is to maintain the network and resources footprint as low as possi= ble. Regard, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com =A0=20 -----Original Message----- From: Rodney Cummings [mailto:rodney.cummings@ni.com]=20 Sent: November-17-15 4:33 PM To: Michel Veillette ; peter van der Sto= k ; Core Cc: Somaraju Abhinav ; Turner, Randy ; Alexander Pelov Subject: RE: [core] CoMI Cool draft splits Thanks Michel, To back up a bit, I think I may be misunderstanding a fundamental assumptio= n in the design of both CoMI and CoOL. Please forgive my ignorance. Of my three points, I think the fundamental point is #3, and #1 and #2 are = just symptoms. To elaborate on #3 with an example, let's say I have a modul= e "foo", with two revisions: - 2011-01-09: original - 2015-08-07: enhanced Both CoMI and CoOL seem to be designed under the assumption that the origin= al revision is a proper subset of the enhanced revision (i.e. objects were = added, but none removed).=20 For CoMI, this is why the client must read the ietf-yang-hash module to obt= ain re-hash mapping. The server presumably promises to leave the hashes of = the original unchanged in the enhanced. Therefore, only the server knows th= e re-hash values, which must be queried by the client. For CoOL, the algorithm for the client to find an automatic DNID is clear. = Nevertheless, the manual DNID (YANG "id" extension) is provided so that the= module author can manually ensure that DNIDs of the original remain the sa= me in the enhanced. As I think through this for the client side, I don't think it is valid for = my client to assume that the enhanced is a proper subset of the original (i= tem #3). I realize that a proper subset is common in practice, but it is no= t guaranteed. From my reading of RFC6020bis, the enhanced module can comple= tely remove all objects from original. Therefore, on the client side, it would be easier for me to assume the "aut= omatic" implementation in the server.=20 In the context of Cool, "automatic" means the automatic DNID algorithm. I w= ould prefer to avoid the "manual" mechanism entirely (my item #1). Rather t= han create CoOL-specific YANG modules, just force the client to process the= normal YANG module assuming that all DNID are automatic. In the context for CoMI, specify an "automatic" algorithm for resolving has= h collisions, similar to CoOL's automatic DNID. This enables a client and s= erver to use the same re-hash, and it avoids the need to query the ietf-yan= g-hash module. Overall, it seems like the most challenging aspects of CoMI and CoOL are th= e "manual" extensions to help with backward compatibility (item #3). To a n= aive reader such as myself, these "manual" extensions make the draft far mo= re complex, and it would be simpler to use the "automatic" technique in bot= h client and server. Rodney -----Original Message----- From: Michel Veillette [mailto:Michel.Veillette@trilliantinc.com]=20 Sent: Tuesday, November 17, 2015 1:21 PM To: Rodney Cummings ; peter van der Stok ; Core Cc: Somaraju Abhinav ; Turner, Randy ; Alexander Pelov Subject: RE: [core] CoMI Cool draft splits Hi Rodney Would you please elaborate your item#2 "A client cannot assume that the YAN= G objects of a module are distinct from a hashing perspective." I'm not sure I fully understand the implications of this statement. The CoOL draft propose to prefix all objects (data nodes, rpc and notificat= ions) defined by a module & associated sub-modules with a common identifier= . What is the impacts of item 2 on this approach? Regards, Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 michel.veillette@trilliantinc.com www.trilliantinc.com =A0=20 -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Rodney Cummings Sent: November-17-15 10:52 AM To: peter van der Stok ; Core Subject: Re: [core] CoMI Cool draft splits Thanks Peter, At this time, proceeding with 4 drafts sounds good to me. Nevertheless, as we get closer to progressing these in a WG, I think we sho= uld transition to 2 drafts: a) YANG to CBOR mapping ( i) ) b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the= function set ( iv) ) for a single draft As for the motivation and use cases, I wonder if it might be helpful to sta= te our assumptions for the client side. I would claim that: 1. A client cannot assume that the YANG modules implemented by the server h= ave been enhanced specifically for CoMI/CoOL. 2. A client cannot assume that the YANG objects of a module are distinct fr= om a hashing perspective. 3. A client cannot assume that a new revision of a module is backward compa= tible to an older revision of that module (i.e. old is proper subset). If these assumptions are correct, then the client must perform some process= ing of the server's YANG modules prior to using CoMI/CoOL, and that may hel= p to decide between hash/registry. If these assumptions are incorrect, it might be useful to discuss it in the= draft, to provide some background rationale. Rodney -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok Sent: Tuesday, November 17, 2015 3:41 AM To: Core Subject: [core] CoMI Cool draft splits Hi all, During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into t= hree parts as suggested by Juergen Schoenwalder in a separate earlier commu= nication. This e_mail sets out in more detail why the proposed split is a good one. The proposed three parts are: 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL) 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) The split has two advantages: - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF - It separates out the issues which need to be solved to merge CoOL and CoM= I. I come to the generation of 4 drafts: i) The YANG to CBOR mapping. ii) Hashing of YANG names iii) Managed identifier assignment to YANG names iv) The Function set specification Ad i) I don't expect a long list of issues for the merging. However, it may= be advisable to submit the draft to the netmod WG, where much of the YANG = expertise exists and the draft can be aligned with the YANG to JSON draft. Ad ii and iii) These approaches are very different and merit independent dr= afts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts.=20 It is also possible that drafts get submitted to other WGs. Ad iv) In my view the alignment of the two existing approaches, CoMI and Co= OL, may take some time. I will be happy if in Buenos Aires we have a list w= ith issues, accompanying motivation, and use cases. Is this a valid approach? Comments are solicited. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org _______________________________________________ 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 Tue Nov 17 14:45:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B311B3496 for ; Tue, 17 Nov 2015 14:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL5cL8MZYaj8 for ; Tue, 17 Nov 2015 14:45:11 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992561B3494 for ; Tue, 17 Nov 2015 14:45:10 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id F11AD4000C; Tue, 17 Nov 2015 23:45:07 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D6B464A; Tue, 17 Nov 2015 23:45:06 +0100 (CET) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 883272E; Tue, 17 Nov 2015 23:45:06 +0100 (CET) Received: (nullmailer pid 4232 invoked by uid 1000); Tue, 17 Nov 2015 22:44:51 -0000 Date: Tue, 17 Nov 2015 23:44:51 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Michael Koster Message-ID: <20151117224451.GA22217@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "draft-jennings-core-senml@tools.ietf.org" , core Subject: [core] SenML JSON syntax and collection+senml+json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 22:45:13 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, hello SenML and core-interfaces people, I'd like to pick up the topic of streamable SenML from the context of the `SenML JSON syntax` syntax thread from before IETF94. To summarize what I know of the state of things: * JSON SenML can't enforce that the base {name, time} entries precede the entries list while still being JSON. To parse a generic SenML message, it is thus required to keep the whole message in memory. An alternative syntax is proposed [{base dict}, [entries]]; that can be extended to allow repetitions thereof (with incremental base values), or the distinction between base and entry data could be lifted further. This assumes that the "e" record list takes a special role in SenML by being the workhorse list of data, which conflicts with: * CoRE interfaces serves collections as both data and metadata in a unified SenML structure, where resource states are given in the classical "e" array, and the metadata next to it in an "l" array as in application/link-format+json. A notation for treating the "l" array as an "e" element was proposed, but did not resonate well with Michael (from the CoRE interface side); I'd like to take up the line of discussion from there: On Tue, Oct 20, 2015 at 12:52:19PM -0700, Michael Koster wrote: > It=E2=80=99s more than a simple visual relationship. I=E2=80=99m used to = JSON tools > that create an in-memory data structure that conforms to the JSON > serialization. With the =E2=80=9Cold=E2=80=9D SenML model, the elements o= f the object > identified by =E2=80=9Cbn=E2=80=9D are rendered as an array within the el= ement > identified by =E2=80=9Cbn=E2=80=9D and tagged by =E2=80=9Ce=E2=80=9D.=20 > > The new construct more than just enables streaming, it forces serial > interpretation, i.e. it *requires* streaming. Yes, and that's the very point. If I'm to parse SenML on a constrained device, especially given that the sender can use its extensibility to send along data that is not expected by the receiver, that means that I need to be prepared to store whichever length the complete message has. For an example of a situation when this can be an issue, take an update to a DMX (RGB spots or other light installations) controller. A PUT to atomically update the complete scene of connected devices in JSON serialization can easily take up 10k plus network overhead in network buffer space even without any additional metadata from SenML extensions, but (if read in a serializable way) implementations could get away with a single-MTU-buffer network implementation plus 1k for double-buffered state. Another example (from my everyday CoAP communication, but not involving embedded parsing) are history readouts of sensor values, which can exceed 100kB for devices with intermittent network connectivity. > Would it make sense to create a new content-format that optimizes for > streaming processing? This is not about streaming Big Data around to the point where big devices need to go into "streaming mode" (though it's useful there too), this is about (not the most common, but still relatively) normal situations and not returning 4.13 from small devices any time someone doesn't chunk up his request to small multiples of the MTU. I don't like to exaggerate, so please take this with a grain of salt and aware that this is written in the heat of the argument: If we don't find an agreeable serialization that can be processed in a streaming fashion, we might right as well put a hard limit to the maximum size of a SenML representation, that are a required minimum for SenML implementors to support. What would that be, 4k? 16k? > > In my opinion, it raises the question of how generic SenML should > > attempt to be. My personal view of it is that SenML is a way of > > encapsulating several resource representations (be they of different > > points in time or different resource) in a single message. With that in > > mind, maybe the following would work for you (rephrasing your example > > into senml-02 syntax, with comments): > > SenML is already being used to represent simple collections in CoRE > Interfaces, OMA LWM2M, and OIC. Whether to have it be extensible and > evolvable or not is certainly a tradeoff against complexity and stream > processing ability. I would lean toward evolvability.=20 Concerning evolvability: That shouldn't be a show stopper: extensions can still go both in the base dictionary and in the events; it's just they wouldn't profit from the guaranteed sequence. An approach I don't like in its current form but that could point the direction for something more elegant is to indicate the "key" of subsequent lists in the base dictionary; with your "l" example, that could be [ {"bn": "/collection1/", "next-object": "e"}, [{"n": "item1", "sv": "value1"}, ...], {"next-object": "l"}, [{"href": "item1", ...}, ...} ] As said, it's not pretty, nor what I'd endorse as-is, but extensibility and easy-to-parse sequence don't necessarily conflict. Concerning focus of SenML: Simple collections seems to be a good outline; would you also agree to "simple collections of resource representations and their metadata"? > > What do you think of the above arrangement? > > I think it=E2=80=99s a substantial compromise in the ability to represent= data > structure to get streaming processing ability. But I do like the idea > of a =E2=80=9Cov=E2=80=9D element for object values. Does that refer to the new serialization format in general or to packing the link list into an entity response in particular? In the latter case, please elaborate -- the latter "happened" with the infrastructure I've been using (under certain conditions, my batch resources contain their application/link-format as "s": entries), I've found it practical, and it would come in much more handy with "ov":link-format+json. Best regards Christian --=20 Christian Ams=C3=BCss | Energy Harvesting Solutions Gm= bH founder, system architect | headquarter: mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614 --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWS63bAAoJEDmNERLTpL3hPGwP/0vErwW9KsPhhEtbZ78/8CIn V/swjsBTBiJcuWHo/riBvfJNb0V8uWKTXAhjGw5/LCJi/IDH00jSTEwSXOG9TdGq UrMQXOmiYcT7goIKB3VLKVqAy4ZfKi4H/A9+EjIV/TuQf2nBw9h0Zga67GRRnprd 7wV5x962mJTZbUWZl4mLj4YHrdEMHlmxro8y2Tx3+MJnumDioLVDTUPzdxAsYMBU qFLcFeoN7IwUeS2Cn6Ahzb/9T9RCNBHiDh4xkDW+D5b2iYxnCce409ug2dzhuFdz PHcExjmRkrgorSgGXPqY0DwtCaU+BHFHhepKRx2mTedDOz6qGWNMu3BGf8YzDywt 7L2xnPqVe0UbPUp3xo2kYOB3aJFWK0MR9WlVEgWJelaTMwA58bTMexHOGEK0gFFM G7L7OETWWQ65yoBTxYadrmxG/PcibTqautb/De5NmYC2KmrIgJUBLFOPdyFGM3sl pXZiJtdLSVLrv7qYlIKLMwcTEq81I4/jCLG4HZsBfV4mbBz4qd8Sr6w8FIAxbCwt SDSGte1koYhn2WszDOr9afXSEm7mBT21vCnhLjeomQLV6hIN8hyFMOpEvJnblsAu ETBhBOkgy8CYfHZTEyRAoKAI99nJ7p9C1jcWVACFNr3f1q9PPDG89m+JdmSt1JFS XNx8CNt/BArv4QWpZuZr =3q6C -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From nobody Tue Nov 17 18:15:29 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80941B37F3 for ; Tue, 17 Nov 2015 18:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGueBXCEEllS for ; Tue, 17 Nov 2015 18:15:23 -0800 (PST) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944471B37F2 for ; Tue, 17 Nov 2015 18:15:23 -0800 (PST) Received: from smtp17.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D08CD180184; Tue, 17 Nov 2015 21:15:22 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C6B4818017A; Tue, 17 Nov 2015 21:15:21 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 17 Nov 2015 21:15:22 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Cullen Jennings In-Reply-To: <20151117224451.GA22217@hephaistos.amsuess.com> Date: Tue, 17 Nov 2015 19:15:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151117224451.GA22217@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "draft-jennings-core-senml@tools.ietf.org" , core Subject: Re: [core] SenML JSON syntax and collection+senml+json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 02:15:25 -0000 Random thoughts on a few subjects: I feel like SenML is getting to complex and we should ask if we can put = it on a diet. Perhaps this streaming is just too much to put into it. An = alternative is to not have SenML do streaming but allow a protocol using = it to support steaming by sending many SenML objects with the convention = that is any given object did not have a base value, then the base values = from the previous SENML object applied. I'm not sure if this is a good = idea or not but I'm just saying that if things start to get too = complicated to do streaming inside SenML, we can punt it up a layer.=20 Complexity : I'm sure someone will think I am nuts for suggesting that SenML is = looking too complicated but as another example ... take InfluxDB which = is pretty good for stuff like this. Ive been using it for a cloud DB for = streaming RT measurements. It deprecated JSON and replaced it with "Line = Protocol" which is effectively the sensor name followed by space = separated followed by the value followed by CRLF. That produced = noticeable improvements in real deployments over general JSON. A big = part of SenML was to *not* be be general JSON and be a very restricted = subset of JSON such that it could achieve the performance of something = like "Line Protocol" or proto bufs and still have some extensibility = story.=20 So Line Protocol would send the example from later in this email as a = single line with=20 urn:dev:mac:0024befffe804ff1/voltage u=3DV 120.1 MetaData: The more I think about metadata and data the less I know which is what. = Consider=20 [ {"bn": "urn:dev:mac:0024befffe804ff1/"}, [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 } ] ] You could argue the only thing that is not metadata is 120.1=20 I think the goal of SenML is to have a record that has a minimal set of = info that is often needed to interpret the data in one record. The base = names were added merely as compression scheme to reduce duplication of = same bits several times. I'm not real wound up about it some of it is = meta data or not.=20 Streaming: When I first read that line that said the latest SenML draft "requires = support of streaming" I thought that was wrong but the more I thought = about it, yes, I think this is a very serious problem with the current = proposal. I was thinking about sensor data being send from a small = device to a big cloud device and this might work OK but in the case of = data going to another small device, this is a problem. It does highlight = the problem of max size for a SenML data.=20 Perhaps we need two different formats - a SenML object and a SenML = stream. That would allow protocols that used this to be clear about if = they used one or the other or both and with HTTP or CoAP, the normal = approaches could be used to negotiate them.=20 > On Nov 17, 2015, at 3:44 PM, Christian Ams=C3=BCss = wrote: >=20 > Hello Michael, > hello SenML and core-interfaces people, >=20 > I'd like to pick up the topic of streamable SenML from the context of > the `SenML JSON syntax` syntax thread from before IETF94. >=20 > To summarize what I know of the state of things: >=20 > * JSON SenML can't enforce that the base {name, time} entries precede > the entries list while still being JSON. To parse a generic SenML > message, it is thus required to keep the whole message in memory. >=20 > An alternative syntax is proposed [{base dict}, [entries]]; that can > be extended to allow repetitions thereof (with incremental base > values), or the distinction between base and entry data could be > lifted further. >=20 > This assumes that the "e" record list takes a special role in SenML = by > being the workhorse list of data, which conflicts with: >=20 > * CoRE interfaces serves collections as both data and metadata in a > unified SenML structure, where resource states are given in the > classical "e" array, and the metadata next to it in an "l" array as = in > application/link-format+json. >=20 > A notation for treating the "l" array as an "e" element was proposed, > but did not resonate well with Michael (from the CoRE interface side); > I'd like to take up the line of discussion from there: >=20 > On Tue, Oct 20, 2015 at 12:52:19PM -0700, Michael Koster wrote: >> It=E2=80=99s more than a simple visual relationship. I=E2=80=99m used = to JSON tools >> that create an in-memory data structure that conforms to the JSON >> serialization. With the =E2=80=9Cold=E2=80=9D SenML model, the = elements of the object >> identified by =E2=80=9Cbn=E2=80=9D are rendered as an array within = the element >> identified by =E2=80=9Cbn=E2=80=9D and tagged by =E2=80=9Ce=E2=80=9D.=20= >>=20 >> The new construct more than just enables streaming, it forces serial >> interpretation, i.e. it *requires* streaming. >=20 > Yes, and that's the very point. If I'm to parse SenML on a constrained > device, especially given that the sender can use its extensibility to > send along data that is not expected by the receiver, that means that = I > need to be prepared to store whichever length the complete message = has. >=20 > For an example of a situation when this can be an issue, take an = update > to a DMX (RGB spots or other light installations) controller. A PUT to > atomically update the complete scene of connected devices in JSON > serialization can easily take up 10k plus network overhead in network > buffer space even without any additional metadata from SenML = extensions, > but (if read in a serializable way) implementations could get away = with > a single-MTU-buffer network implementation plus 1k for double-buffered > state. >=20 > Another example (from my everyday CoAP communication, but not = involving > embedded parsing) are history readouts of sensor values, which can > exceed 100kB for devices with intermittent network connectivity. >=20 >> Would it make sense to create a new content-format that optimizes for >> streaming processing? >=20 > This is not about streaming Big Data around to the point where big > devices need to go into "streaming mode" (though it's useful there = too), > this is about (not the most common, but still relatively) normal > situations and not returning 4.13 from small devices any time someone > doesn't chunk up his request to small multiples of the MTU. >=20 > I don't like to exaggerate, so please take this with a grain of salt = and > aware that this is written in the heat of the argument: If we don't = find > an agreeable serialization that can be processed in a streaming = fashion, > we might right as well put a hard limit to the maximum size of a SenML > representation, that are a required minimum for SenML implementors to > support. What would that be, 4k? 16k? >=20 >>> In my opinion, it raises the question of how generic SenML should >>> attempt to be. My personal view of it is that SenML is a way of >>> encapsulating several resource representations (be they of different >>> points in time or different resource) in a single message. With that = in >>> mind, maybe the following would work for you (rephrasing your = example >>> into senml-02 syntax, with comments): >>=20 >> SenML is already being used to represent simple collections in CoRE >> Interfaces, OMA LWM2M, and OIC. Whether to have it be extensible and >> evolvable or not is certainly a tradeoff against complexity and = stream >> processing ability. I would lean toward evolvability.=20 >=20 > Concerning evolvability: >=20 > That shouldn't be a show stopper: extensions can still go both in the > base dictionary and in the events; it's just they wouldn't profit from > the guaranteed sequence. >=20 > An approach I don't like in its current form but that could point the > direction for something more elegant is to indicate the "key" of > subsequent lists in the base dictionary; with your "l" example, that > could be >=20 > [ {"bn": "/collection1/", "next-object": "e"}, > [{"n": "item1", "sv": "value1"}, ...], > {"next-object": "l"}, > [{"href": "item1", ...}, ...} > ] >=20 > As said, it's not pretty, nor what I'd endorse as-is, but = extensibility > and easy-to-parse sequence don't necessarily conflict. >=20 > Concerning focus of SenML: >=20 > Simple collections seems to be a good outline; would you also agree to > "simple collections of resource representations and their metadata"? >=20 >>> What do you think of the above arrangement? >>=20 >> I think it=E2=80=99s a substantial compromise in the ability to = represent data >> structure to get streaming processing ability. But I do like the idea >> of a =E2=80=9Cov=E2=80=9D element for object values. >=20 > Does that refer to the new serialization format in general or to = packing > the link list into an entity response in particular? In the latter = case, > please elaborate -- the latter "happened" with the infrastructure I've > been using (under certain conditions, my batch resources contain their > application/link-format as "s": entries), I've found it practical, and > it would come in much more handy with "ov":link-format+json. >=20 > Best regards > Christian >=20 > --=20 > Christian Ams=C3=BCss | Energy Harvesting = Solutions GmbH > founder, system architect | headquarter: > mailto:c.amsuess@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr > tel:+43-664-97-90-6-39 | = http://www.energyharvesting.at/ > | ATU68476614 From nobody Tue Nov 17 18:22:57 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633371B3837 for ; Tue, 17 Nov 2015 18:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BShebutVLHb4 for ; Tue, 17 Nov 2015 18:22:55 -0800 (PST) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15C81B3836 for ; Tue, 17 Nov 2015 18:22:55 -0800 (PST) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 13AB1380196; Tue, 17 Nov 2015 21:22:55 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6E508380171; Tue, 17 Nov 2015 21:22:54 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 17 Nov 2015 21:22:55 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Cullen Jennings In-Reply-To: Date: Tue, 17 Nov 2015 19:22:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6375801A-E176-4A03-A9C1-A5A0568CD51A@iii.ca> References: <20151117224451.GA22217@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "draft-jennings-core-senml@tools.ietf.org" , core Subject: Re: [core] SenML JSON syntax and collection+senml+json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 02:22:56 -0000 trivial correction ... > On Nov 17, 2015, at 7:15 PM, Cullen Jennings wrote: >=20 > So Line Protocol would send the example from later in this email as a = single line with=20 >=20 > urn:dev:mac:0024befffe804ff1/voltage u=3DV 120.1 Right after sending that I realized it should have been=20 urn:dev:mac:0024befffe804ff1/voltage,u=3DV v=3D120.1 (the tags are separated with comma not space) but not much difference. = Sorry.=20 From nobody Tue Nov 17 20:15:01 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AA01AC3D8 for ; Tue, 17 Nov 2015 20:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm2O9FWCsAcz for ; Tue, 17 Nov 2015 20:14:56 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 573241AC3D2 for ; Tue, 17 Nov 2015 20:14:56 -0800 (PST) Received: by lffu14 with SMTP id u14so18570872lff.1 for ; Tue, 17 Nov 2015 20:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tRZ/ImTOnzoSAkpEJOyTENb7soM0Bgz90VtvKm4jRGo=; b=hMbok82LnHl50b9+6ozRZSmvzQj2HvJJUg+xGr5zOEBfeUQo2VbGcoNGwt9yHbyIM4 EcLWbzrPpp0kCAmqKDczq7LPIoF33XVgXgSab7gs9km1LePBtSts0bgg3axlLId06KtW gOqbrw6ysViwDT2PFVsuSMRjYO5Czse/QqogKyScrOV8/VOpWeuNDKdrVxDvgWcEzHgC ykQ91echAw0TOAa1NS71AzVWWBFz5Z0rRCRgjsWyEl6lHR+znbZQmd/US8E++90q53rF cbCzr/kdlHIQK2djSiFSA9LBTv6AaCrgPjhhS0JqwCo1wzAX2eQoSvViaggBaU3X6Fwc P/ug== 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:content-type; bh=tRZ/ImTOnzoSAkpEJOyTENb7soM0Bgz90VtvKm4jRGo=; b=k9R3wNs2aMc/OC6gZ2/q5YiYID3V8hEHdg5h2/amAw05hjNrYuCVW05cVdODFP4YVL Xac+yRsQmEsGxgZFGLYrOXEcJ50y+VCTpZRwNecDS53k9R39IL7qdSJqY4F1GbWI38sh vEb3HPO1jgOGzxnYgIZLXoxg7k7NhJQ1WcuoGGNnkMylpX2GKRnkXBY1X6Rhvt++Tcnp qcLlaPJ1bGKR3z+Eltfw8fvx76vkEBZVbVeAM3SITBkK46gCzySGoryPM1Enno7X4Adw 8DMHKeWOnZZ5Y4tDAqOPwZNtQKXR/orfC59+TPzJbg38Oeyu+rz62VDYV3JbBeuzdEq3 1ASw== X-Gm-Message-State: ALoCoQmgLlPwHsuv04e/XFOL8ovTDz3JrSc9ypLrW8Ap7FYftiPH5ThPS0MwNJ8OPZn9cNKbtJqA MIME-Version: 1.0 X-Received: by 10.25.205.135 with SMTP id d129mr6475972lfg.32.1447820094249; Tue, 17 Nov 2015 20:14:54 -0800 (PST) Received: by 10.114.3.234 with HTTP; Tue, 17 Nov 2015 20:14:54 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Nov 2015 15:14:54 +1100 Message-ID: From: Andrew Mcgregor To: Core , draft-tschofenig-core-coap-tcp-tls@ietf.org Content-Type: multipart/alternative; boundary=001a1142104a6aeff80524c8e25f Archived-At: Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 04:14:59 -0000 --001a1142104a6aeff80524c8e25f Content-Type: text/plain; charset=UTF-8 And it looks like we have pretty good consensus from the list as well. Authors, please submit your next version as a WG draft under the name draft-ietf-core-coap-tcp-tls. On 3 November 2015 at 15:38, Andrew Mcgregor wrote: > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the Constrained > Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 > -- Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 1071 2221 --001a1142104a6aeff80524c8e25f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And it looks like we have pretty good consensus from the l= ist as well.

Authors, please submit your next version as= a WG draft under the name=C2=A0draft-ietf-core-coap-tcp-tls.

On 3 November 2015 = at 15:38, Andrew Mcgregor <andrewmcgr@google.com> wrote:=
The sense of the room a= t IETF 94 was that we should adopt this as a working group document.
This is the corresponding mailing list call, open until Novemb= er 16.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A TCP and= TLS Transport for the Constrained Application Protocol (CoAP)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Carsten Bormann
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Simon Lemay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Valik Solorzano Barboza
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hannes T= schofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draf= t-tschofenig-core-coap-tcp-tls-05.t= xt
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-11-02

Abstract:
=C2=A0 =C2=A0The Hypertext Trans= fer Protocol (HTTP) was designed with TCP as the
=C2=A0 =C2=A0underlying transpo= rt protocol.=C2=A0 The Constrained Application Protocol
=C2=A0 =C2=A0(CoAP), whi= le inspired by HTTP, has been defined to make use of UDP
=C2=A0 =C2=A0instead of= TCP.=C2=A0 Therefore, reliable delivery and a simple congestion
=C2=A0 =C2=A0co= ntrol and flow control mechanism are provided by the message layer=C2=A0 =C2=A0= of the CoAP protocol.

=C2=A0 =C2=A0A number of en= vironments benefit from the use of CoAP directly over a
=C2=A0 =C2=A0reliable by= te stream such as TCP, which already provides these
=C2=A0 =C2=A0services.=C2=A0= This document defines the use of CoAP over TCP as well as
=C2=A0 =C2=A0CoAP ov= er TLS.


The IETF d= atatracker status page for this draft is:
h= ttps://datatracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/

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

A diff from the previous version is avail= able at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-tschofenig-core-coap-tcp-tls-05

--
Andrew Mc= Gregor=C2=A0|=C2=A0SR= E=C2=A0|=C2=A0andrewmcgr@google.com=C2=A0|=C2=A0+61 4 = 1071 2221



--
--001a1142104a6aeff80524c8e25f-- From nobody Tue Nov 17 23:22:55 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FE21B29A6 for ; Tue, 17 Nov 2015 23:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVjqrwN8iSkv for ; Tue, 17 Nov 2015 23:22:52 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A3D1AE4CB for ; Tue, 17 Nov 2015 23:22:50 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id ivNm1r00F4aYjWA01vNmRx; Wed, 18 Nov 2015 08:22:48 +0100 Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 08:22:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 18 Nov 2015 08:22:46 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Message-ID: <6145d483aea5794d3aff738ef0fdf3cf@xs4all.nl> X-Sender: stokcons@xs4all.nl (iJyMK7gnV+JtdQ9wetx8WjCz4/vAC9fj) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 07:22:54 -0000 Hi Michel, thanks for our approval. We are on the road now. I am preparing an e_mail on the YANG to CBOR mapping to be sent to-morrow. It takes some time to go through all details. Cheerio, Peter Michel Veillette schreef op 2015-11-17 20:19: > Hi Peter > > The 4 drafts you propose make lots of sense. > > I propose to start by the item 'I' (The YANG to CBOR mapping), follow > by item 'iv' (The Function set specification), follow by items 'II' > and 'III'. > I propose this order since examples in the latter will be based on the > first two deliverables. > > I have extracted section 4 and 5 of the CoOL draft as starting point, > see attachments. > Do you accept this contribution as strawman for this work? > > Should we create a specific mailing list for this work? > > Regards, > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com 聽 > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: November-17-15 4:41 AM > To: Core > Subject: [core] CoMI Cool draft splits > > Hi all, > > During the Yokohama meeting I proposed to split the CoMI/CoOl drafts > into three parts as suggested by Juergen Schoenwalder in a separate > earlier communication. > This e_mail sets out in more detail why the proposed split is a good > one. > > The proposed three parts are: > 1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in > CoOL) > 2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL) > 3) The YANG name compression (section 5 in CoMI; section 6 in CoOL) > > The split has two advantages: > - the parts 2 and 3 can be used in other contexts, e.g. RESTCONF > - It separates out the issues which need to be solved to merge CoOL and > CoMI. > > I come to the generation of 4 drafts: > i) The YANG to CBOR mapping. > ii) Hashing of YANG names > iii) Managed identifier assignment to YANG names > iv) The Function set specification > > Ad i) I don't expect a long list of issues for the merging. However, > it may be advisable to submit the draft to the netmod WG, where much > of the YANG expertise exists and the draft can be aligned with the > YANG to JSON draft. > Ad ii and iii) These approaches are very different and merit > independent drafts. The CoRE WG can decide to adopt 1, 2, or none of > the two drafts. > It is also possible that drafts get submitted to other WGs. > Ad iv) In my view the alignment of the two existing approaches, CoMI > and CoOL, may take some time. I will be happy if in Buenos Aires we > have a list with issues, accompanying motivation, and use cases. > > Is this a valid approach? Comments are solicited. > > Peter > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Tue Nov 17 23:27:42 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2101D1B29C0 for ; Tue, 17 Nov 2015 23:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQAj0Mle6Ncj for ; Tue, 17 Nov 2015 23:27:39 -0800 (PST) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20171B29B5 for ; Tue, 17 Nov 2015 23:27:38 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id ivTd1r00E4aYjWA01vTd8h; Wed, 18 Nov 2015 08:27:37 +0100 Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 08:27:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2015 08:27:37 +0100 From: peter van der Stok To: Andy Bierman Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (gHSJBHn/qvQ53utq7WS8KCqNmR55ELyW) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 07:27:40 -0000 > > I think the YANG Hash draft should be separate from the protocol. > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > I agree with Andy here. Although I sympathize with Rodney, that once the four drafts are reality, the WG should decide about adoption and a recombination of documents. Peter From nobody Wed Nov 18 00:09:40 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394861A00A8 for ; Wed, 18 Nov 2015 00:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7-AWpWpKp_O for ; Wed, 18 Nov 2015 00:09:35 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1201D1A009C for ; Wed, 18 Nov 2015 00:09:34 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id iw9X1r00L4aYjWA01w9XXd; Wed, 18 Nov 2015 09:09:32 +0100 Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 09:09:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 18 Nov 2015 09:09:31 +0100 From: peter van der Stok To: Alexander Pelov Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <82c7667140aeaa28efab31a778a26204@xs4all.nl> X-Sender: stokcons@xs4all.nl (zVIVVpJxFWIsNTKeEKqSIa24phm5HRWH) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: [core] Your cool presentation on friday core meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:09:39 -0000 Hi Alexander, I like to react to your presentation of CoMI during the Friday CoRE meeting. That is necessary for me to understand the underlying factual discussion. Your statement 鈥淎 hash clash 5 years down the road can break your network鈥 needs some clarification. I interpret that, out of the blue, a hash clash can occur and lead to problems in the network. This is simply not true. A new hash clash may occur when modules are changed and recompiled in a server. At that moment and before the server is made operational hash clashes are detected and remedial actions can be taken. Your next statement 鈥渉ashes are underspecified鈥 also needs some clarification. I understood from you that the remark was motivated by the absence of a full-proof process defining the solution of hash clashes. Such a process is not necessary to assure inter-operability. Once solved, the server returns the unique rehashed values and there is no need to specify how the rehash values are reached. Nevertheless, the draft suggests that a tilde is prefixed to the YANG name, after which it is rehashed. There is a very small probability that the new hash clashes with another one. Actually, you said to be afraid that the hashing algorithm may continuously generate the same set of clashing values independent of the prefix. I have no idea if this is true, and do not propose to check it for murmur. I agree that for efficiency reasons the same rehash process should be followed in all servers such that all servers with the same set of module versions arrive at the same rehash values. An approach different from rehashing is to assign the lowest not assigned natural number to the clashing names in lexicographical order. That will generally mean that two colliding names get the values 1 and 2 assigned, and very rarely the values 3 and 4 may be used. Last I should like to make a remark about probabilities. The whole world around us is based on probabilities. For example, there is a finite probability that a fatal fault will occur in an airplane during one hour of flight. Or that during digital transmission bits are toggled without detection by the checksum. These probabilities are calculated and should be smaller than a given probability value. This is a well-established engineering practice. Therefore, the clash probabilities are calculated in appendix E of the CoMI draft. It shows that for the targeted hash size and number of names, the probability that more than one clash occurs is 10^-3 smaller than the probability of one clash. These are quite small values. By the way, by relying on identifier assignment, there is also a finite probability that the same identifier is allocated to names on different modules (a hidden clash), due to power failures, undetected transmission errors, or simply copying mistakes. I recommend that in the security section of the identifier assignment draft, it is discussed how modules are detected with an identifier that has been assigned without going through the registration process. Hope this will stimulate further discussion. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org From nobody Wed Nov 18 00:31:27 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6CC1B2A0C for ; Wed, 18 Nov 2015 00:31:26 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUjfXb7f8jRQ for ; Wed, 18 Nov 2015 00:31:19 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB5F1B2A0A for ; Wed, 18 Nov 2015 00:31:18 -0800 (PST) Received: from AMSPR06MB198.eurprd06.prod.outlook.com (10.242.91.144) by AMSPR06MB103.eurprd06.prod.outlook.com (10.242.90.148) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 08:31:03 +0000 Received: from VI1PR06CA0022.eurprd06.prod.outlook.com (10.162.116.160) by AMSPR06MB198.eurprd06.prod.outlook.com (10.242.91.144) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 08:31:02 +0000 Received: from AM1FFO11FD015.protection.gbl (2a01:111:f400:7e00::112) by VI1PR06CA0022.outlook.office365.com (2a01:111:e400:587c::32) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Wed, 18 Nov 2015 08:31:02 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATBRAGMSX01.itiso.net; Received: from ATBRAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD015.mail.protection.outlook.com (10.174.64.93) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 18 Nov 2015 08:31:02 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATBRAGMSX01.itiso.net ([169.254.1.64]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 09:31:01 +0100 From: Somaraju Abhinav To: "consultancy@vanderstok.org" , Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbW5jNwRAHeU+Rg/6jmUcLNJ6gTL6AgAAcVgCAAOkigIAAHgWE Date: Wed, 18 Nov 2015 08:31:00 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD015; 1:/pN9Wh1RYD6E7yRTq7tC/3TMhwBaYYkCz5BI75z02khxzDLA140F7PXwkHNrQAQ7AXI6zFhuRLvw/KbIAYxoVy/PDlITozRTmAAGSaijQrzK3QMrpNrc/2BOpUSWe/MhAjPkri/gMi3IDHdl9A44i1N9H7pqa1TVD/X9BYiAiCLQWh807x3+Sdg3ETUixuAzNbfBkLERKrklnN4zSH8czf2hx2H8aExkvR3aIATexb/7tJrJ3Q/80xW/PtP9AYZYvJSNl+/EVnXEn/EoIXWzGqsDz8MbGJvsTDAJwCmUNFNyFZ3hfL7q0UP/XrtVFPwrP1hApGREXrB0lmAgQhY0MsKI6su+pfu+S8Ma/jwvK9k= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(57704003)(199003)(377454003)(189002)(106466001)(104016004)(5890100001)(11100500001)(561944003)(23726002)(97756001)(92566002)(5004730100002)(76176999)(54356999)(53416004)(55846006)(46406003)(2501003)(5003600100002)(6806005)(5007970100001)(86362001)(106116001)(5008740100001)(50986999)(5001960100002)(69596002)(19580405001)(5001920100001)(19580395003)(189998001)(50466002)(81156007)(586003)(87936001)(102836002)(85806002)(15975445007)(26826002)(2950100001)(66066001)(2900100001)(93886004)(47776003)(5001770100001)(2920100001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR06MB198; H:ATBRAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB198; 2:SbBQQAX8E2M6sciUcVcxsXXkeWwozge0X4zY+319g0qtrusxrt9f4Z72V1/b/WXzq06B9sgXTSMKh+n78BtzlBfDMoXjjf9kwAJZ0W3iCj/Hqg0RNCRy2wLuPb1grOAvCokqQqCr+TxWu9ecmPeqGke85u5zIJjAiZsEBbOW6ps=; 3:dimplYMBfw7Kmsjc3Ei68NRN/EmkW2T/PKr7oISOF29FJHZJKzDgLbrYMbQVvB6nK9WqsrmBC5maLRs4HfLTGYOlTUePO5WR0okRD0IFNnE+KFgyTdT5N2yobS/PnV8jcEk1h4PvF9DTHP6m3YpVPKDQUbDKWcFrwN9l0FgP5JiFNhp3gkFSfcE2RaM35zmZ3FeLXq1RNakkHEXVT6yt0nUQR85W4YQxCsx8HYyMt8aJDaGfA8sot5xQWI2TsmyAeoxotGpI+x9ojzWqQVUDiQ==; 25:idMJB3YXXavydIOWzM/RxaSCTmruBToU2+M4eCJ+N+00UlfCQINKCG7Ku1acBxEZBQ4rfkdO7YlBs91Gochf3qQhlqY7pB89t3lO/OLLnMHk81WEKNQgNp9HMQZh068xV8a8rt15iNMWezWiC5xXhMOUhadhd4jJ2DFV3hBa5x/RJOxQSZz+s2V8OX3OiHkLfxVnLweXhb6RUTd1gYw4zD3xzn9Yiwy3I/0J6CVdWJW6CXX8RkbkfBPOUJLAcgD0LWrsgIoHpFntazsWP0Z+NA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AMSPR06MB198; X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB198; 20:6192cIrjNX1hWIaRkJ34vHXs8PwrjHxQHgswS5+rFO54ILExzOrjqtU2d9dgzNmN2VltUNPHjp1uXrNntxK1gtPcp8Is/R9zOMpUyWL14Rl0kPRtxsMAMR5vgYpl9EYKGakie6DFYJm56770n7Vy48wxqqmq8b7ccdg5t6/1vMURu8NQebg0MI/1Vs0hPvYsgQfCDuNTkIsnAZ5Hzs5rUCnMZF6c6dWytUGeTfc/p6Mca6g+qBWEdhxOT66hfM27eAkNZ/VKdjrt5803dDQtL4HgKBMS75w9XWsluk/BL0sbtxK98ybtjzDSVkHr5f9AwEGl9a61AW1WFxGlXToc2Sl6Ofask9TJFx3LUqQjoRPa5WSFd5fXcC/NxKYTH4aDdeZE/yhpTPFtdWXhxmoyiTzqGeC/cU14uAcd8kcOpBgTmK1BBjB02NGpewNUvphz+3FvOrMplpvBxRIJ0jCpIfVvKeP0iFU1pGIgwOueFvqb3Km6RJsJmyRUvYh+7kC8; 4:CnPlkwL68jgeyaTYv10GPU8dkEhqMXeJInbfAH2Fq+RpKBmr/u+Z8PaK8k2zQ33i9aK3Rl6NLtiJt49fBwK/v8/5dbLsT1BNuM5lSyN9H+HuJWHbp+HxJK9Zg3ceVq0lvRxtYdVdbduJxa1NeUcW7U9dBpLS3VasUf03Bl297FgUXG0k/XrKw/mZUvXi+HE3ap2c/qL/G5YbadIj4sPxjfGtwbaGeCOASae2GhZmJVBopSFFqINgnrmhKuG3315msXEc+frL1duXODDv8KjmaDwyaYJL+4Qx0jS3xnkGSeEHz71MNzUHZdeY3zjGFp35Zp8FNMDHvwv1WBdw4C+0SyRgiWUUSrQeBLvNBuIpxV2khggrgiyIlb/yYdVRDriB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(262738631018165); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR06MB198; BCL:0; PCL:0; RULEID:; SRVR:AMSPR06MB198; X-Forefront-PRVS: 0764C4A8CD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AMSPR06MB198; 23:z+mE7f1vjRK6Zg0AlGo2+iOHWTZyDkKcnLq042vggL?= =?us-ascii?Q?iKkINFBazhzA3R9i75TUodL87/lD/33tkuL0UbSyQxfE2hhPKD70JUoSiaGf?= =?us-ascii?Q?GKmV7k57cTJTe5lP7vK8h8bCV2Y4dbDYIUMRkGleTPsLc4dli0N31+3Xwy/f?= =?us-ascii?Q?Q79yGVKiSl/VXrPoHBTfrJFJ+8Q9v4P3IR03FIZHXln3BV4MPxKLSn5UfiXs?= =?us-ascii?Q?UUrJ/ZjqSlUgp2ZZcopNB2tB2CKTLb4YL4yAOsKyAQAPi2rYQw4MJ9bTMMHU?= =?us-ascii?Q?jvgyFV+9URpSNilrZa1NzIrPae13uMpTsxLifb+XMnfDUiIZOlqQ6+jPZZ5/?= =?us-ascii?Q?hr3SDWqziD4M7M6+JlXgDiM76piPOBeBcHFn/+X9CQMUMrxASfUuV/o4v71l?= =?us-ascii?Q?KvYrWKBvB3Dh6H3w56cVLFA56H9cWyVoiUoWzaF535GA6RsRlofipcWjKQtZ?= =?us-ascii?Q?SaeFCFjopTIzGVgMfrdLmI4lPaDYW7u/B6b2j+iS3fIjdr9TIz5R0NVXbii3?= =?us-ascii?Q?lc6vHSbXTW4tz5YGJEoXmkPbCJ2y2NYlXMC0qtZb90oYBCG3zS6/J3KlnEey?= =?us-ascii?Q?0Y5o3iPINUjLpwj/6wugZYUPKnjrn+XfXZU7mcGCgebzsmXHQ2AvXMUepPz9?= =?us-ascii?Q?vZI8zZck1EK4l8wvU9EYwQ+lAHG8vMSuuu0v0rNcogLxCMZss+4beLp/qn9Y?= =?us-ascii?Q?nIRI7kJvVmY/iay581rV7p/m91K87l6TaAVX871Xv+3OD3oinISb+MDesQTD?= =?us-ascii?Q?aQsbSr2mDFlMeB+GiSiWeS/vY7UriiEvuU1Sa8JGbuXYX7F5VSpiFixeMrX+?= =?us-ascii?Q?f7wilw/5UheLKxLqRyHn5aEDDyGb7U95oah5YsdnkMnup6t8e0fG+ie3Vr7t?= =?us-ascii?Q?sYpjQg7gwnWa0hxQYYyjYTBG+eSjckfsvrJGDeiuTnkt0o50D3gcNJ4t2ZEF?= =?us-ascii?Q?AcVIOKbVQJqJtXdem9mkjX1d+gv57U9krfiCQAcFuqiQ8igY2VzkfYClFsdg?= =?us-ascii?Q?eqIBwjalAm7cJBUyBIo4Af6mKU6CToUXDh+fd5svKSou1WbT4WN8jVKLbuG6?= =?us-ascii?Q?iesooHE7YstTa1Pgg3W4Q4BEHMSF+ml+Hw/iStwBdjt58U3jv3RX1V/bQIBm?= =?us-ascii?Q?uFxFxwQk1bhwOh8s7h8smungscNwBCKaEPduNJDeDxcwQ0zXMAUfhgj0vzkW?= =?us-ascii?Q?cx6uNYs1xKOYIqCG+0A/VPXgss0VdnZpy/7W57dfAGG2ZMJnxP19o6WkJqRO?= =?us-ascii?Q?bM2Q0zfcsZneh7ORleWG++rl/D8LaLkWLf3WlFG8lPcmh2r90pUI7Z6opKP0?= =?us-ascii?Q?hxsI4/ga34h6LHnXPKptgYeMhwT0QSk3upKcq9q8fVswxXawEqydZEyx3V1R?= =?us-ascii?Q?fgpg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB198; 5:dQvE/CilXbSXHwjH6z9/o5NDglf/O4vNuZ5jcv8XJgfPosvRG0kAj3SOo9B1K4hVFnbwx4sdlPnB5wytj9xEznGI8Bx8UfUk+G8K9sNidwHl5tHfQCtUPaPNv4aT0DtmvmUF16dpbPWilqNjyEgWNw==; 24:jjAW3Ruc9nl1CQrWVrSPddayOdOHZZLlNg8Ucbt9h9yGDjeKpZRMO2eFaEl4KZoMdDZly3OzP5JVEqTyiiD3ICk+Xe4jiHZrTsFcImugCS8=; 20:pNrmF1eYh2KEHF7p58YJ3aqR4+mydj2LOPrBq3fzzqE+gYo87uQQ9tIwR39nwyU9bmP4nbpl0G57gJstuucDyw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 08:31:02.1463 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATBRAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR06MB198 X-Microsoft-Exchange-Diagnostics: 1; AMSPR06MB103; 2:kdhg6MSwfCHIpYA0ewhfmhQGTxWxUuEWkF/bctGAfudG3DptnbTd4YO3+8bralpKcOTrl7xF218fav0ve0AurExz+h/ozYmy7uP9XA5O7cEZ/SpNvzOOGe+18ik3XoY7SybdHVD+bNZfE0kUbmL7VSAmx+oKbD8Tgnaks9NgmZs=; 23:jqoSp1bA/Ufd1/uAac/YXlQ5NWs0a7/2quj2s6RCl+ds/IF96SUG9XBiNIo0depYjAMgk2aGVLz1k76PIxz4T8/tR7toWiiJydJ7fzqQMRR0zG1I+KSX8Ptax3c0QhkHCjbWuDH/odW9KKKUT7ymQVwfNSkkNQgDRaNS1wxMSPw1tSpJstJ+C9JspCTgZx6E X-OriginatorOrg: tridonic.com Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 08:31:26 -0000 Hi Peter, I like your proposal of starting with the four drafts. Just a few comments - Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my = opinion, in constrained networks we will not support two management protoco= ls one for networking and one for application layer. Therefore, we should s= upport both in the function set. - Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But from= the perspective of being able to use a device management protocol, unless = we also get interoperability for access control/security mechanisms, the dr= afts will not be usable in the field. - Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numberi= ng scheme as far as possible. So, my questions is the following: do we need= data node IDs consistent across versions of YANG modules. Abhinav ________________________________________ From: core [core-bounces@ietf.org] on behalf of peter van der Stok [stokcon= s@xs4all.nl] Sent: Wednesday, November 18, 2015 8:27 AM To: Andy Bierman Cc: Core Subject: Re: [core] CoMI Cool draft splits > > I think the YANG Hash draft should be separate from the protocol. > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > I agree with Andy here. Although I sympathize with Rodney, that once the four drafts are reality, the WG should decide about adoption and a recombination of documents. Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________________________________ 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 Wed Nov 18 02:23:31 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7007B1B2BD2 for ; Wed, 18 Nov 2015 02:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO-t98_6N4AH for ; Wed, 18 Nov 2015 02:23:26 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BACF1B2BCD for ; Wed, 18 Nov 2015 02:23:26 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id iyPQ1r00A4aYjWA01yPQL1; Wed, 18 Nov 2015 11:23:24 +0100 Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 11:23:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2015 11:23:24 +0100 From: peter van der Stok To: Somaraju Abhinav Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> Message-ID: <4df325ff9500dbdae6f981ac577400d7@xs4all.nl> X-Sender: stokcons@xs4all.nl (1pEma60ThxKPWh5SNlyYxg/ZowCUeABm) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 10:23:29 -0000 Hi Abhinav, see below. Somaraju Abhinav schreef op 2015-11-18 09:31: > Hi Peter, > I like your proposal of starting with the four drafts. Just a few > comments > > - Before working through iv) function set, I think it makes a little > bit of time working out what use cases we want to support. In > particular, I think we should decide if we are only going to address > Netconf/Restconf support or if we expect to support Yang application > layer module management. In my opinion, in constrained networks we > will not support two management protocols one for networking and one > for application layer. Therefore, we should support both in the > function set. I agree about support for management and others (which needs a bit of thought) > > - Access control. I think for iv) function set, we should also think > about how access control is going to work while we look at the > function set. I don't know if this is a separate draft in a different > WG (e.g. ACE). But from the perspective of being able to use a device > management protocol, unless we also get interoperability for access > control/security mechanisms, the drafts will not be usable in the > field. Again I agree. In the security considerations this should be put forward. I was more thinking of referring to the drafts developed in ACE and COSE than on specifying security separately for CoMI/CoOL. One of my problems is also the support of Multicast, and I don't see the appropriate draft being approved quickly. > > - Regarding Versions of YANG modules: I do not understand why we need > consistent numbering when a module version gets upgraded. As Rodney > already mentioned, we can not assume that new versions of a module are > supersets of old versions. I think it is also important to keep using > the automated numbering scheme as far as possible. So, my questions is > the following: do we need data node IDs consistent across versions of > YANG modules. on the other hand there are the YANG rules as Andy pointed out; My take-away till now is that consistent data node IDs across versions is VERY difficult, and probably not needed (to be checked in detail) > > Abhinav > > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of peter van der Stok > [stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 8:27 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] CoMI Cool draft splits > >> >> I think the YANG Hash draft should be separate from the protocol. >> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >> > > I agree with Andy here. > Although I sympathize with Rodney, that once the four drafts are > reality, the WG should decide about adoption and a recombination of > documents. > > Peter > > _______________________________________________ > 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. From nobody Wed Nov 18 04:50:21 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE691A1AFC for ; Wed, 18 Nov 2015 04:50:19 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC5QTCOKkgiI for ; Wed, 18 Nov 2015 04:50:16 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168421A1AE3 for ; Wed, 18 Nov 2015 04:50:15 -0800 (PST) Received: from VI1PR06CA0065.eurprd06.prod.outlook.com (10.163.160.33) by AM4PR06MB1473.eurprd06.prod.outlook.com (10.164.80.27) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 12:49:55 +0000 Received: from AM1FFO11FD054.protection.gbl (2a01:111:f400:7e00::149) by VI1PR06CA0065.outlook.office365.com (2a01:111:e400:533c::33) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Wed, 18 Nov 2015 12:49:56 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX02.itiso.net; Received: from ATDOAGMSX02.itiso.net (146.108.200.10) by AM1FFO11FD054.mail.protection.outlook.com (10.174.65.73) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 18 Nov 2015 12:49:55 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX02.itiso.net ([169.254.4.122]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 13:49:54 +0100 From: Somaraju Abhinav To: "consultancy@vanderstok.org" Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbW5jNwRAHeU+Rg/6jmUcLNJ6gTL6AgAAcVgCAAOkigIAAHgWEgAATGACAADjMlA== Date: Wed, 18 Nov 2015 12:49:54 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC724@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>, <4df325ff9500dbdae6f981ac577400d7@xs4all.nl> In-Reply-To: <4df325ff9500dbdae6f981ac577400d7@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD054; 1:eCygAiLPMW2aU+w213RmTzyRvxW9w8vguYILFOAmlOa/dQR2OspTYSPuo5Z5DcHVUOEgd4axW3tCAJIhxUNqVNmMViwsN+R4OZmMLHpBud90uKhZ/OAOJm2nGUio4OwsBvI/E+8vGb2xGJVahrV/wkxwyumVB7D4qdPsFJa2PdxKkJ9e8Cx8mBzBpfAshfmwEtaYduEN1SrsWFMJD78gGTwPr0HtPv/ToKgP853TluWNRA3N2+/lmFSJbnvA0e1rbQOvLV5oRir67B3F9cYuJylm66SVmADDR3BzlicKJaZJgzNGK953TL4Y0qUxfyU34BbAc14Vg3UjgXvxRfjuoMK7vIFksD3QRv6LBUYANbU/nKsOsheL/rE4lyMmZUGZ3qxkPIoWzhaYx/F0cRxuKg== X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(377424004)(377454003)(57704003)(2950100001)(2920100001)(102836002)(561944003)(15975445007)(26826002)(33656002)(2351001)(54356999)(46406003)(2900100001)(5001960100002)(50986999)(23726002)(81156007)(5003600100002)(4001150100001)(189998001)(93886004)(5007970100001)(110136002)(5004730100002)(87936001)(5890100001)(86362001)(6806005)(2501003)(106116001)(97756001)(76176999)(53416004)(106466001)(55846006)(104016004)(586003)(5008740100001)(69596002)(19580405001)(19580395003)(50466002)(92566002)(66066001)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR06MB1473; H:ATDOAGMSX02.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1473; 2:5baHX7PAmDdzfTZMkuCZGnvaxAUPhaDuD7Y7JrliC2hrWeq3JOtK6uEqcK8bmoTnVn559OltNYxd70Is+yjpAGTg4XlYo8IggO285tmwKBZLUFU/GMSfkAJpq4ivckTQJ1f7iJrOnJqPXViKK5l3oh3jmCeMMUcNshtLnHvonYs=; 3:WaAgK8vq/xZy8bHpL8iVVcZgbYFuxaJQUmD949G9WzirjNXOxMm2s/ued+XLaNdO02DUH1MeINjqvjny/oFj4jpxJsL/a4e74wJFPZoEREy2lYMFkJ+sFblEF0sRTbvOAooRcujk7KqqCL7laNI6dkhW8YNt9V8majjc804ZhS27ga6VtiH6hWHVRxdd5VIWJ2/HGJM/moHpvA77gDseVHiumqVwjfGLfnP8aHIjOG9ZKWyv+rnVK3TTduMyx7Nzp7txPVo2H68A7Wr9mYG07A==; 25:SVTVhY7t66ANjDr7y8rgEH4O22a74bhQqgMCkR5ol92ArqTFrhrvUjgFuSe1OFdZYD0iehRlKuqFxJQCrYkFcGF+yrZ3SlV9azGCi1QswaWVPZZCSSOOitTJbn5yE21DLXnVBY6jk2ApUm/BuKURdccXQa/U4LWoc/jraHWaP46o2sMauGf9/uu8ORBUfL+2AQaxQf2EXtRmmuga4NjIxSevuaxb1/MI8UMqaCdfgF/YWw9qSaPqyW0TqylthYikU3QKAj9GKvr7RAn6uAgIEg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM4PR06MB1473; X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1473; 20:jWRZLjJ+oLf1ZsGwkDDJ/3GyML5heD9s/T+ENos4vVxZCiC2bSHuO+LF/HyRS8W8YsPgKdVOhqxT0v741JelG4pY5t4mNgZX3sbZw9jfBemwFLHTQy9WKrqv/05JrjX2TTanCOStNDiRIO8Q78VZ1Ao5b4bTnHUhl3w0gSZzJ6JM9iEpHUy0pMw66B4UOJULB75YrGOVSjVIW9BM0J+ZHWYiwA20DT9r2XAV4TAaLeJNwwZltYI8aYZj6mNGZuaVVjwJmtcXYEib/huTvf+z14nACsvKJokXGEwvnYcbK/ZBNOcQc6E1XM9yBjvDtfnGE6nHE6w5xJ3VwlyLy4N4HoELO8rk2gmZ4d0KgDJ0Lwiqudb5IZFA8BxeyHAK32aJSZdl0qfFl/5t17MIngvtgzHO1832DxMz38QvV9W07llWubiEN74+EI5VEhmdGhQ9PP4YMNc1t74e7DgD81Togk7toI17Y79rf8mca+6wxX5iZhwtDOX3xDe2scg3jvBm; 4:T8PyTRMh8oUy5/NRUcXvHwmuiC7o1ZQbzy3ZADq9lOPh4hNEmqWl8cMFoPbtQYGONa6I6EE+Sy7vbnzGAMa76c86zoDHAamawQndQ17ZQm40R3VcoL6wjS3VBgp6w5NsJRb4SSVe88slQAap/L0PrwBnBPiPHQKCRB+ac5eSUbDUMly0iGYx/ggkIImUviO73VP8v1jwueO7ef6C5zGd7IKiaP7wCTC32b6fjLlciuJufHNA7mm+CE/EikzULuYTcoV7MZKk6SbfZ+Tg1OUZQY1W9RW6z/b+VQe994a5nmTfA+tO00L6vVx3yhhNmjZTdq+3v1EsuIGfi9EBI5L4uE4sOHFWsPgsRx8NxPCI/OuN88Dg3NQ9NYv4bcbvzHDz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(262738631018165); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:AM4PR06MB1473; BCL:0; PCL:0; RULEID:; SRVR:AM4PR06MB1473; X-Forefront-PRVS: 0764C4A8CD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM4PR06MB1473; 23:p/2mBPGLvpqfA/IAviCMmDZJcom9DhSu3z/vUdivB?= =?us-ascii?Q?tA5ymeHoDfCSewBQuOh+fWs/s9W1OyfDkrh1v13sgHNfEbDDl7oCGfGVXYuo?= =?us-ascii?Q?2yaeSjLP8TgAjltB3cR/JCsw8Rw0cSn/RHsgKtPvLPU0bc+ly1ou9eIolps0?= =?us-ascii?Q?UsGjRTjhP5LFs5PsCv8gvsyv/C2VFoonOrhOU/jknW6GO/5ofHb1YERjTWVd?= =?us-ascii?Q?KQ1jI3HddKUiQjw3+wfFiL2zO0zUa95Uf2p/ligvuQvAiAabEoSKBpgU53W/?= =?us-ascii?Q?AbRiBZZiEdyr0BHIAtTdIA7/mq0g/dY7J1OQrbIrC4d2RnhYdIftwb0Sz13J?= =?us-ascii?Q?mQCZPStueH4jk+F8vsAsORGJ0mVvjrXVwbhxefIiqqhr4fsc8te2200zaNqE?= =?us-ascii?Q?fN2wCMG9nFxBZ3LLd8SgttxoKmysqeSu4OSqqTPw62l6muS0r5XpfXX8s9Ba?= =?us-ascii?Q?/+CfbA8PE826D+il/pohx/g4K4nrqze1tRB+iDLEk+s4SQC5jpLlBJ8yG4H/?= =?us-ascii?Q?6rMj0N+cdNxlIPkL9ooeyfYzUMicxQelLI4imzw3Pux5XCWuD+c1WNuubXWi?= =?us-ascii?Q?SAc13apx8ULAIShnlJirS6sTOdc2qzERkB+Yw/SN4aFqElMWNfKckQJZE8pP?= =?us-ascii?Q?9IrRsE96+zp2NKj0cHUEj6lDwMUY6WA+K15Kmpst3MnkGEm4cxVGjQQO49PT?= =?us-ascii?Q?D8tjo2OP4i7XHOpe6qo9yVdfBnZYiHPBl6YMHj2J1NyskJOCEEMyZWSBydpS?= =?us-ascii?Q?32V7r7rQ9xQso4ZtbKQifGO7ZLGb5TcimrABoDABng+mxgstr0FsmTwnwTNA?= =?us-ascii?Q?IhefpaTgP3ROWNso2Ujf02LMZP8iFrRYi3OjLm2G79VKG0qJxrNHcDT5C6fu?= =?us-ascii?Q?sWd8YOVrV0xO6QXs1p1Py5C4BA/NCESvZTcWvCFKK0d8EDNzOUOdSeh/SIK6?= =?us-ascii?Q?tR8jkGLXUZFYfipxR3+vEqhNQ7QmePk9zbKqLIwEq5lHy8+E58/QemneptfJ?= =?us-ascii?Q?5AWQHokSoMNBDxe+L3DbkKHazYEdtHNocCHLevnuhY0N0/3lYJuSQvArjQ0o?= =?us-ascii?Q?8Gb84E639Jo3RhClYecqiux0ogQcSWeMp9EKc1MDtiREM3CpjW7R+JDlu6g6?= =?us-ascii?Q?qSWYMgXw5SwmCSArVYTwyYtKbjMNiMeUi4Ynr1xzMU2iUHFHDZWsBTslq19l?= =?us-ascii?Q?GOY+fQW319PEl0hfJFcEI5CPZuQXZ/MVS4PhvRcMAVwlulytPPZK1j2ZFdp6?= =?us-ascii?Q?zdUe9QhUezlycuhuM7HNHzBlozZSB3R6RTrVJaZ2L40lCVngGo/WU+/yEDQ6?= =?us-ascii?Q?elqB3HaAMFWmjzMYXNfxkmdARtY1RoPdIfAUckm6FUDHjk4z2disd6+okZM2?= =?us-ascii?Q?xFhsg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR06MB1473; 5:TkgqBXp+mY3toYDwUfdQDCkMg9pUTQGmBaFpyX5UJTXGU1Jh9HDEC3Cu38rSYKM6KSTQS6E7dSwhMrkhwwzWZB6lUQ4ElFF2+giJzL7HoM70OgDOG2xROqMaT+dZ7PMrHYbY4rNAtj1vVQqiTn0Tgw==; 24:1nwkngV9dBcZOxjvsecWsWAc3TQymAPjxilcZe0PUWkGxbNd/mfRC4s8N0T043dgVS60aVBTi4ndVAUCyyn7UU47wZeOIJRTuAr1Y0Sfexc=; 20:aeckU2GNYDxdSNf31ww1FjNc8K84ya7xVJFdiHMNnyKH3WENcyI+9h7i5SciLVq2IlP7XG88NhTaDMYePyvFaQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 12:49:55.6811 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX02.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR06MB1473 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 12:50:20 -0000 Hi Peter, About "I was more thinking of referring to the drafts developed in ACE and = COSE than on specifying security separately for CoMI/CoOL". I don't expect that we specify the actual security protocols that will be u= sed in CoMI/CoOL - this is clearly the domain of ACE/COSE. However, I think= we should specify which ones to use in which context and how. E.g. for the= discovery part, we might say reply to any message. We should also provide = discovery methods of which protocol is may be used to actually secure get/p= ut request. I do not think these types of issues will be covered in ACE/COS= E but are in the domain of the management protocols. Regards, Abhinav ________________________________________ From: peter van der Stok [stokcons@xs4all.nl] Sent: Wednesday, November 18, 2015 11:23 AM To: Somaraju Abhinav Cc: consultancy@vanderstok.org; Andy Bierman; Core Subject: RE: [core] CoMI Cool draft splits Hi Abhinav, see below. Somaraju Abhinav schreef op 2015-11-18 09:31: > Hi Peter, > I like your proposal of starting with the four drafts. Just a few > comments > > - Before working through iv) function set, I think it makes a little > bit of time working out what use cases we want to support. In > particular, I think we should decide if we are only going to address > Netconf/Restconf support or if we expect to support Yang application > layer module management. In my opinion, in constrained networks we > will not support two management protocols one for networking and one > for application layer. Therefore, we should support both in the > function set. I agree about support for management and others (which needs a bit of thought) > > - Access control. I think for iv) function set, we should also think > about how access control is going to work while we look at the > function set. I don't know if this is a separate draft in a different > WG (e.g. ACE). But from the perspective of being able to use a device > management protocol, unless we also get interoperability for access > control/security mechanisms, the drafts will not be usable in the > field. Again I agree. In the security considerations this should be put forward. I was more thinking of referring to the drafts developed in ACE and COSE than on specifying security separately for CoMI/CoOL. One of my problems is also the support of Multicast, and I don't see the appropriate draft being approved quickly. > > - Regarding Versions of YANG modules: I do not understand why we need > consistent numbering when a module version gets upgraded. As Rodney > already mentioned, we can not assume that new versions of a module are > supersets of old versions. I think it is also important to keep using > the automated numbering scheme as far as possible. So, my questions is > the following: do we need data node IDs consistent across versions of > YANG modules. on the other hand there are the YANG rules as Andy pointed out; My take-away till now is that consistent data node IDs across versions is VERY difficult, and probably not needed (to be checked in detail) > > Abhinav > > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of peter van der Stok > [stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 8:27 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] CoMI Cool draft splits > >> >> I think the YANG Hash draft should be separate from the protocol. >> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >> > > I agree with Andy here. > Although I sympathize with Rodney, that once the four drafts are > reality, the WG should decide about adoption and a recombination of > documents. > > Peter > > _______________________________________________ > 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. ________________________________________________________ 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 Wed Nov 18 05:40:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243651B2D75 for ; Wed, 18 Nov 2015 05:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpJZY8TMsd72 for ; Wed, 18 Nov 2015 05:40:18 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2638A1B2D77 for ; Wed, 18 Nov 2015 05:40:12 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud3.xs4all.net with ESMTP id j1g91r00N4h15BW011g9W9; Wed, 18 Nov 2015 14:40:10 +0100 Received: from [2001:983:a264:1:7d10:d66b:502e:d9a6] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 14:40:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2015 14:40:09 +0100 From: peter van der Stok To: Somaraju Abhinav Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC724@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>, <4df325ff9500dbdae6f981ac577400d7@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC724@ATBRAGMSX02.itiso.net> Message-ID: <7f5687445bf002fb241bd0e945287d52@xs4all.nl> X-Sender: stokcons@xs4all.nl (60kA58gl3odi6mDpPJipvRorDYx/UadK) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 13:40:21 -0000 Hi, I see that we agree. However, drafts are mostly about inter-operability. We must make security recommendations but I can imagine that other SDOs want to specify under which conditions these protocols are used. Peter Somaraju Abhinav schreef op 2015-11-18 13:49: > Hi Peter, > About "I was more thinking of referring to the drafts developed in ACE > and COSE > than on specifying security separately for CoMI/CoOL". > > I don't expect that we specify the actual security protocols that will > be used in CoMI/CoOL - this is clearly the domain of ACE/COSE. > However, I think we should specify which ones to use in which context > and how. E.g. for the discovery part, we might say reply to any > message. We should also provide discovery methods of which protocol is > may be used to actually secure get/put request. I do not think these > types of issues will be covered in ACE/COSE but are in the domain of > the management protocols. > > Regards, > Abhinav > ________________________________________ > From: peter van der Stok [stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 11:23 AM > To: Somaraju Abhinav > Cc: consultancy@vanderstok.org; Andy Bierman; Core > Subject: RE: [core] CoMI Cool draft splits > > Hi Abhinav, > > see below. > > Somaraju Abhinav schreef op 2015-11-18 09:31: >> Hi Peter, >> I like your proposal of starting with the four drafts. Just a few >> comments >> >> - Before working through iv) function set, I think it makes a little >> bit of time working out what use cases we want to support. In >> particular, I think we should decide if we are only going to address >> Netconf/Restconf support or if we expect to support Yang application >> layer module management. In my opinion, in constrained networks we >> will not support two management protocols one for networking and one >> for application layer. Therefore, we should support both in the >> function set. > > I agree about support for management and others (which needs a > bit of thought) >> >> - Access control. I think for iv) function set, we should also think >> about how access control is going to work while we look at the >> function set. I don't know if this is a separate draft in a different >> WG (e.g. ACE). But from the perspective of being able to use a device >> management protocol, unless we also get interoperability for access >> control/security mechanisms, the drafts will not be usable in the >> field. > > Again I agree. In the security considerations this should be > put > forward. > I was more thinking of referring to the drafts developed in ACE and > COSE > than on specifying security separately for CoMI/CoOL. > One of my problems is also the support of Multicast, and I don't see > the > appropriate draft being approved quickly. > > >> >> - Regarding Versions of YANG modules: I do not understand why we need >> consistent numbering when a module version gets upgraded. As Rodney >> already mentioned, we can not assume that new versions of a module are >> supersets of old versions. I think it is also important to keep using >> the automated numbering scheme as far as possible. So, my questions is >> the following: do we need data node IDs consistent across versions of >> YANG modules. > > on the other hand there are the YANG rules as Andy pointed out; > My take-away till now is that consistent data node IDs across versions > is VERY difficult, and probably not needed (to be checked in detail) > > >> >> Abhinav >> >> ________________________________________ >> From: core [core-bounces@ietf.org] on behalf of peter van der Stok >> [stokcons@xs4all.nl] >> Sent: Wednesday, November 18, 2015 8:27 AM >> To: Andy Bierman >> Cc: Core >> Subject: Re: [core] CoMI Cool draft splits >> >>> >>> I think the YANG Hash draft should be separate from the protocol. >>> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >>> >> >> I agree with Andy here. >> Although I sympathize with Rodney, that once the four drafts are >> reality, the WG should decide about adoption and a recombination of >> documents. >> >> Peter >> >> _______________________________________________ >> 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. > ________________________________________________________ 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. From nobody Wed Nov 18 06:23:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C511B2E30 for ; Wed, 18 Nov 2015 06:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9dle5IomPjl for ; Wed, 18 Nov 2015 06:23:07 -0800 (PST) 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 25ED91B2E2B for ; Wed, 18 Nov 2015 06:23:07 -0800 (PST) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 32179FB8A9; Wed, 18 Nov 2015 15:23:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id r-1BfBwaTn8a; Wed, 18 Nov 2015 15:23:03 +0100 (CET) X-Originating-IP: 193.54.23.146 Received: from Zax.local (unknown [193.54.23.146]) (Authenticated sender: alex@ackl.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 6A5E4FB8DC; Wed, 18 Nov 2015 15:23:03 +0100 (CET) To: consultancy@vanderstok.org References: <82c7667140aeaa28efab31a778a26204@xs4all.nl> From: Alexander Pelov Message-ID: <564C89C6.40903@ackl.io> Date: Wed, 18 Nov 2015 15:23:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <82c7667140aeaa28efab31a778a26204@xs4all.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] Your cool presentation on friday core meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 14:23:09 -0000 Hi Peter, I'm quite busy these days. I would like to send you a detailed response, but unfortunately this will be impossible today. Please, see in-line for some initial remarks. Le 18/11/2015 09:09, peter van der Stok a 茅crit : > Hi Alexander, > > I like to react to your presentation of CoMI during the Friday CoRE > meeting. That is necessary for me to understand the underlying > factual discussion. > > Your statement 鈥淎 hash clash 5 years down the road can break your > network鈥 needs some clarification. I interpret that, out of the blue, > a hash clash can occur and lead to problems in the network. This is > simply not true. A new hash clash may occur when modules are changed > and recompiled in a server. At that moment and before the server is > made operational hash clashes are detected and remedial actions can be > taken. One of the specific cases I cited is, when you have your network running for months, maybe several years, before updating a YANG module, which leads to hash clash. This leads to unexpected protocol exchanges (e.g. clash-file loading), unexpected memory allocations (the clients must learn that some of its servers have these new clashes, while others have some other clashes, and so forth), bugs that have not been tested for long time, ... > Your next statement 鈥渉ashes are underspecified鈥 also needs some > clarification. I understood from you that the remark was motivated by > the absence of a full-proof process defining the solution of hash > clashes. Such a process is not necessary to assure inter-operability. > Once solved, the server returns the unique rehashed values and there > is no need to specify how the rehash values are reached. Nevertheless, > the draft suggests that a tilde is prefixed to the YANG name, after > which it is rehashed. There is a very small probability that the new > hash clashes with another one. Actually, you said to be afraid that > the hashing algorithm may continuously generate the same set of > clashing values independent of the prefix. I have no idea if this is > true, and do not propose to check it for murmur. I've though on how to handle this specific question for a long time, and unfortunately you cannot guarantee that re-hashing will no guarantee new hash clash. Which could, in turn, generate new clashes. Each clash leads to two new names that need to be rehashed. > > I agree that for efficiency reasons the same rehash process should be > followed in all servers such that all servers with the same set of > module versions arrive at the same rehash values. An approach > different from rehashing is to assign the lowest not assigned natural > number to the clashing names in lexicographical order. That will > generally mean that two colliding names get the values 1 and 2 > assigned, and very rarely the values 3 and 4 may be used. I think that Structured IDs provide a way of handling this in a reasonable manner. We've already discussed how in a structured ID you can have hashes. > > Last I should like to make a remark about probabilities. The whole > world around us is based on probabilities. For example, there is a > finite probability that a fatal fault will occur in an airplane during > one hour of flight. Or that during digital transmission bits are > toggled without detection by the checksum. These probabilities are > calculated and should be smaller than a given probability value. This > is a well-established engineering practice. Therefore, the clash > probabilities are calculated in appendix E of the CoMI draft. It shows > that for the targeted hash size and number of names, the probability > that more than one clash occurs is 10^-3 smaller than the probability > of one clash. These are quite small values. > What constitutes a "small probability" is a relative question. 10E-3 is typically considered quite elevated (not to say - unacceptably high) collision probability. Given that you can have hundreds of entries, this probability is even worst. Given that each collision requires re-hashing, which could provoke other collisions, we end up with a problem I consider to be quite dangerous. > By the way, by relying on identifier assignment, there is also a > finite probability that the same identifier is allocated to names on > different modules (a hidden clash), due to power failures, undetected > transmission errors, or simply copying mistakes. > I recommend that in the security section of the identifier assignment > draft, it is discussed how modules are detected with an identifier > that has been assigned without going through the registration process. > That's a non-issue. > Hope this will stimulate further discussion. > > Peter Thanks for the useful remarks. I am glad when we have constructive discussion. Sorry, for the brevity. Best, Alexander From nobody Wed Nov 18 07:05:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D8B1B3240 for ; Wed, 18 Nov 2015 07:05:08 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2A1k_LNOcWo for ; Wed, 18 Nov 2015 07:05:04 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4FA1B324B for ; Wed, 18 Nov 2015 07:05:04 -0800 (PST) Received: from AM3PR06MB148.eurprd06.prod.outlook.com (10.242.245.19) by AM3PR06MB291.eurprd06.prod.outlook.com (10.242.108.23) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 15:04:47 +0000 Received: from HE1PR06CA0007.eurprd06.prod.outlook.com (10.162.181.145) by AM3PR06MB148.eurprd06.prod.outlook.com (10.242.245.19) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 15:04:46 +0000 Received: from DB3FFO11FD029.protection.gbl (2a01:111:f400:7e04::194) by HE1PR06CA0007.outlook.office365.com (2a01:111:e400:51fa::17) with Microsoft SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Wed, 18 Nov 2015 15:04:46 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by DB3FFO11FD029.mail.protection.outlook.com (10.47.217.60) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 18 Nov 2015 15:04:45 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 16:04:44 +0100 From: Somaraju Abhinav To: "consultancy@vanderstok.org" Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbW5jNwRAHeU+Rg/6jmUcLNJ6gTL6AgAAcVgCAAOkigIAAHgWEgAATGACAADjMlP///i2AgAAoHvQ= Date: Wed, 18 Nov 2015 15:04:43 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC877@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>, <4df325ff9500dbdae6f981ac577400d7@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC724@ATBRAGMSX02.itiso.net>, <7f5687445bf002fb241bd0e945287d52@xs4all.nl> In-Reply-To: <7f5687445bf002fb241bd0e945287d52@xs4all.nl> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD029; 1:+zGPhhFp5jsJ92d+MeAUZS2ROvpjLrbm9p6/Sds4gU++mp/KO5VhY6FyV7dyroMfKrEQuOXpU0Xd4NW3Waml2Z6up1ksNyVBPdepmutNngiiaNL7hbOTZclazMzYePc3GYrVRrrISTm5Yd2ZxYbLBHzC92ecLqaqXFsqMFRIKwuDR7kk+glBWgRA4jTvTPVBItgSJb4zlpOMR1zugss0OXRlnZwublwpTCnfjH1DlYrm4XTAQYwRlL/XVJvbIj2drj4mtKQwwX4CcK4CXD3umzl775M1ooXCZ7MXYVwQM7Fwd0jBdT05oPn4OP86BSV6QPkhQ+TR9O/0lgNnJjrFUVGxZMFm1uREAiYNulsxMnlqFLVgXmSkU1ZJNzNLOlgf X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(189002)(199003)(57704003)(377424004)(189998001)(19580405001)(86362001)(19580395003)(110136002)(5001960100002)(106116001)(69596002)(81156007)(33656002)(586003)(50466002)(5890100001)(4001150100001)(87936001)(53416004)(2501003)(92566002)(5003600100002)(5007970100001)(5004730100002)(23726002)(2351001)(106466001)(5008740100001)(6806005)(104016004)(11100500001)(76176999)(46406003)(54356999)(102836002)(93886004)(2900100001)(55846006)(561944003)(47776003)(26826002)(97756001)(50986999)(66066001)(15975445007)(2920100001)(2950100001)(586874002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB148; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 2:69vizN17tdNJi52ljbbMpEDOLv5oZtpj2k9ueIlxWDNLy1FQQA5Xlbx1NANaA3PJwy9sddcGIAyQt3EM/QXpO2Q8w+2KYWBuM8TXX1kuOw/82OQZyO1Ey9CZF6Z90iffsmGlDf8frzLjdcyKnDXaDqNvxYgIeecjaeqRDmB4oSQ=; 3:Rtss6TbgAmySmGUZhSh5teE6imjCC3mKboEg5NwD2qsk1w8gkXGzzoxY7Qv28D26ZmTgtzQYxeNeYDoZ7Ss0Xp24y2obTkT5C1nD9EPTKapEgRjB4z7KnnkZYrVf3vZv39jT1z0KViNctbdoDA3eaJf30aRi7NCM9Y5f0zpiLO9fVLfgkTu7RatxV/rr8FpnCIHsMD+GIkoWqMGIFdwUKq1UNCHqdfL+jEvbkVA/3NjCITMYv4GCgQjpb5fgPYqGcI1+cxP2EsCCc61Nzku0Mg==; 25:dZVItBisUtjJJTrusX5T3QevlBEvrqiXy9tShFwbKDjoWu/t2zq6LeBaGX+Qk+LH0Q7BP+t3VU/7VtjaqrhGAJbGoVsRbmrTXff0lNokoLLMUtKpt5yVEAvL7KgOVLT552KoHBDHAS29t8byqgwqTPw8MDy/twME7aNm7wXSctZ5rmfk6ZXaq8wsccOFZ2NkTBrrz6vjzYfHntOO2DtzkWTE3trUNENwwQoaoeLhsrDqnXRm+1tspGMnD5Gaat7RaWOySdJ1spOlquoQe+Am8w== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM3PR06MB148; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 20:qY3KF+dRHZMk0SDXPRNh876GQpasAJysvZ4RA1zMNwLo2M0IOsXxDgOdyQpEwwYpcrLBiTN7tsuL5HDr+xXJ0CYb//LvMQW52Iofuv15Bx7TBPm0W09JjyLvb0+fC8zh3LHknUtwBOGFIJULF75pABfg0dxlJuZ0e0CogF6c1WWuz4p7wdY+ZwfZx6M3AoEGzVn7G9e6weKomvCKz/vDeTiH74NMlBZ7ZCkKIhxJiliu/D7Ocbb+OB909c1ucuX7QPJq6WM/64ECAEF487vjS0Y8WSbbNT7VKwDBQokMnmquUJCnmt0SJBYxqexxoh7ujdiy77SZSF72HmVRRQdm7NS+mYCr+P38Lw4+p64Zg8ME5hD7iduOnlSGe+99slxLMUKJtoFO9YL4MzGkvAi9SNvEV5tZddqZS1rqen0a8WxmECJT+snbAsj9u3jTCDsC4FXf1M1vUsGOumafBnClIfaXmL23nWrZBbb0qj+wDtaMYorIzt5FtQBg7wFZAobD; 4:08lE9CD9xUxdt0/lqdgVsSqoEGeW1GySQloBgVh4dRTwUIMS4VOapJPUI8HcO5/BRNKEvbUED4agcAQO+u+qqrQ6teTH9p9d+Xk1JIDLLI3yCHPcB9FzgUvm2nHXJdZBdMqV9fRYVpC+gidE1pjYJjHBMjWXuDo4lUR2ERiYFTytKMgGmJOtZ7KJZOp/YkiSIY326p1AY79ODxjaYH9aWcEUfiJSzaVZvOBiv/4bb6DBRCa9vMRGbfXFFSwY+iseFycHNCmhDnohffYSk+TiSbHJX3PSJK6xyQNfoodCuJEo458Y13Gv6DkNnvt3khKdx9H33FP3M53TtD7Kxkv2LthUNUKt5HnOZBBsXStuTEFsNf9Y++oJOhzrUO0xNtqB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(262738631018165); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AM3PR06MB148; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB148; X-Forefront-PRVS: 0764C4A8CD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR06MB148; 23:yxaRpssChoTTDmf4yvcZXEK6u3F6EuZT+Dtrk6bR90?= =?us-ascii?Q?0DdlTWrkdIU2H8cujn2ioa2zjmNOOREnajegfPQeHvl2nxIpdBJdfO6cnoLU?= =?us-ascii?Q?PYJDImcwi+l9I3PJFL33RMKxGc3vzG+6hIOJbft3qQZlzFi3ULpxZjAz3vKg?= =?us-ascii?Q?eJLJw5DP2qIJwVe39h6aNSIhQC9TCIa3ofrmY/ZRU4kBIu+9XdCOC3TiYclI?= =?us-ascii?Q?VMwX8uWWAhAbrZRCELBLiW4rx1+f5jo3nzxJJOUrzkiN4onWk1IQ/FWdA68z?= =?us-ascii?Q?Bz2z2dSGMY5HQtCgDNHQe7L4eido/HwoyHcH44NMj8+7vgetM7IWgBmtrzo6?= =?us-ascii?Q?m3deB/WalirA705whemIrUh8XaMkTg49XOMbCabfG/k4WbonOEXpbETg3DB9?= =?us-ascii?Q?1MLuvF/pGEj5AIL7TmHWgL/tJkuO/rbOKbJR6UjRpaqcSde/Yr7y9QIoDaXv?= =?us-ascii?Q?4AFlGNJPEzdK2Ye+MrkC4prqBHSJfszZw4ZcGa3IBdDOTRRdH5BueRuXpg/Q?= =?us-ascii?Q?liX6qXgt+8Gvf0/zrU+NLa2UGAZsVVGlboUWGbY6mY5rs9aRF3Z5gdbC4lFd?= =?us-ascii?Q?AL3183POaTCRjckveev52lAZjmHi3IF7+m8xFU5XjHie6ge6aanJAjbwMhfM?= =?us-ascii?Q?tLJrIY3QxJyOSRad8VSZAgQ8NnTTi4cfq/dvapymSZCu4PWKHxbra0zdfFr0?= =?us-ascii?Q?aQxl++sh1OdJ08c2DOQ3mipIP7NI8VQjOcXSZvb62ttUvXMpBPTebo0ayVat?= =?us-ascii?Q?nxpnkYAuyPNdioP9MbULBz1bxg0lHahPuFyTXKMF+9iMCpqh6P2PXpfiRYgx?= =?us-ascii?Q?p8B2hWWb4VzcMphsAoHmxhqybtOluyNeqaUdrPqCNtV9WNCUcDl6e2NA89pE?= =?us-ascii?Q?0HE5lwyTUtAO4wqQQUx/hyXwTqmp3Tt5hS/PsE4DHt+tfOvnt3888NFlpYWW?= =?us-ascii?Q?+i/UAkNhTXxQnXkS+Ba48ucwALUriPdj7xGKC1wrk8QV3oTH0shGpJqMaPHH?= =?us-ascii?Q?42IyOCn+tlPaDAM3KsDYxE65E9+8qhmlNbORv7cOgGCsevDiQmP1mRMEJPtl?= =?us-ascii?Q?s+Bhcp5lN6ONnrn4vKofNW8JivUg6M36QkPIeRD4vpSlVN4datHfOIe6WEYN?= =?us-ascii?Q?8/Dmal0QNFvMVwGfFZW6YSuR3Jq+vJ7NVp6+vpFdOXfyb+4TeB+aRf5p9t9r?= =?us-ascii?Q?4ACjqr60eTePLqQKTnXV4s1GdK27uhsh/FBbHwocRd45wySjxy3SM9PHHv6z?= =?us-ascii?Q?mUMnWLOcimC5UgtLAEoHlHPSYW0lgA0PuOzEdaAP7zcz1ZjtrzRDj0CW9x3U?= =?us-ascii?Q?IUkqfP2tpdxTGpR1sPrPfR1otJy80fMA22pDaNucH9KooFqvJgIalVLrVk1h?= =?us-ascii?Q?voBEClffv2tX+t+WIQ5XBuehc/dlwJTQ5Vvk+uObBe2vq0?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB148; 5:PoekvYCB9wBpJvevHk7SZZiO1ZFYEYRKIBLT5isnA97Jam/T5Xb70rq1wdSsQYW5RNkqipIORDLx7I2s2fQhmcf3SXfwNFWCSBLjfJVgBrTqtYV4fraK2/PWISd1Bf4iAKlyFzacLlegq/r4lBA1Ag==; 24:DgaLraxpxGVPM3R7X6EU3KFothpIsGWzdV9Kmt9nOiJyPebq9rrwp1AuLBhJdpODyUT9/xTZArJNrHYFqQGVb74sX4L27PGxJh+a8jcYJvg=; 20:IUXpVUhfE1wo4D2GxkIIKkJDk7//LiNuMJ6SGbwb27eNj6xwJieaFpbrEvVXKw8eXUicfelyAVrqwIKJKYo+nw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 15:04:45.6546 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB148 X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB291; 2:+cOEMcBLnao9SygFgevZX9EGokC8aENLpoTpzn7GAKrKR2lge78+9ZPH9ySOnwUaztxF2Y11JfHo7flc4zStIjLkN0iUg22SlIB1UMV8xLOYTfOYZCrcfjDbREUzLXnHMOCcT/pNtLwFg0amE6Spve30BytX5O72QGyZSTr6VBw=; 23:2kjcZ7QEZcObenWVKIKw7RAe+q4zI1s3tyZNEXx0QgbRgr0PbGPX3HMrVkfDT9vVW2LaAR1B54Rv+LLkNTvEUEYuXMlSMUWHiLvjcscZ7r1cJABwa9D+UKm06h/Pz/gNPIVVL65Ucua7YjmmqegRtLXyZB/ZWZ8+N1MCjxTBw/oszGpt9pDayMmWD4QAKHCw X-OriginatorOrg: tridonic.com Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 15:05:08 -0000 ________________________________________ From: peter van der Stok [stokcons@xs4all.nl] Sent: Wednesday, November 18, 2015 2:40 PM To: Somaraju Abhinav Cc: consultancy@vanderstok.org; Andy Bierman; Core Subject: RE: [core] CoMI Cool draft splits Hi, I see that we agree. However, drafts are mostly about inter-operability. We must make security recommendations but I can imagine that other SDOs want to specify under which conditions these protocols are used. [AS] Okay. Fair enough if we assume an SDO will specify conditions under wh= ich the protocols are used. Peter Somaraju Abhinav schreef op 2015-11-18 13:49: > Hi Peter, > About "I was more thinking of referring to the drafts developed in ACE > and COSE > than on specifying security separately for CoMI/CoOL". > > I don't expect that we specify the actual security protocols that will > be used in CoMI/CoOL - this is clearly the domain of ACE/COSE. > However, I think we should specify which ones to use in which context > and how. E.g. for the discovery part, we might say reply to any > message. We should also provide discovery methods of which protocol is > may be used to actually secure get/put request. I do not think these > types of issues will be covered in ACE/COSE but are in the domain of > the management protocols. > > Regards, > Abhinav > ________________________________________ > From: peter van der Stok [stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 11:23 AM > To: Somaraju Abhinav > Cc: consultancy@vanderstok.org; Andy Bierman; Core > Subject: RE: [core] CoMI Cool draft splits > > Hi Abhinav, > > see below. > > Somaraju Abhinav schreef op 2015-11-18 09:31: >> Hi Peter, >> I like your proposal of starting with the four drafts. Just a few >> comments >> >> - Before working through iv) function set, I think it makes a little >> bit of time working out what use cases we want to support. In >> particular, I think we should decide if we are only going to address >> Netconf/Restconf support or if we expect to support Yang application >> layer module management. In my opinion, in constrained networks we >> will not support two management protocols one for networking and one >> for application layer. Therefore, we should support both in the >> function set. > > I agree about support for management and others (which needs a > bit of thought) >> >> - Access control. I think for iv) function set, we should also think >> about how access control is going to work while we look at the >> function set. I don't know if this is a separate draft in a different >> WG (e.g. ACE). But from the perspective of being able to use a device >> management protocol, unless we also get interoperability for access >> control/security mechanisms, the drafts will not be usable in the >> field. > > Again I agree. In the security considerations this should be > put > forward. > I was more thinking of referring to the drafts developed in ACE and > COSE > than on specifying security separately for CoMI/CoOL. > One of my problems is also the support of Multicast, and I don't see > the > appropriate draft being approved quickly. > > >> >> - Regarding Versions of YANG modules: I do not understand why we need >> consistent numbering when a module version gets upgraded. As Rodney >> already mentioned, we can not assume that new versions of a module are >> supersets of old versions. I think it is also important to keep using >> the automated numbering scheme as far as possible. So, my questions is >> the following: do we need data node IDs consistent across versions of >> YANG modules. > > on the other hand there are the YANG rules as Andy pointed out; > My take-away till now is that consistent data node IDs across versions > is VERY difficult, and probably not needed (to be checked in detail) > > >> >> Abhinav >> >> ________________________________________ >> From: core [core-bounces@ietf.org] on behalf of peter van der Stok >> [stokcons@xs4all.nl] >> Sent: Wednesday, November 18, 2015 8:27 AM >> To: Andy Bierman >> Cc: Core >> Subject: Re: [core] CoMI Cool draft splits >> >>> >>> I think the YANG Hash draft should be separate from the protocol. >>> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >>> >> >> I agree with Andy here. >> Although I sympathize with Rodney, that once the four drafts are >> reality, the WG should decide about adoption and a recombination of >> documents. >> >> Peter >> >> _______________________________________________ >> 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. > ________________________________________________________ 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. ________________________________________________________ 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 Wed Nov 18 08:33:03 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30701A1A62 for ; Wed, 18 Nov 2015 08:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3eamv1ji0no for ; Wed, 18 Nov 2015 08:32:59 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 313341A1A50 for ; Wed, 18 Nov 2015 08:32:59 -0800 (PST) Received: by lfaz4 with SMTP id z4so30196328lfa.0 for ; Wed, 18 Nov 2015 08:32:57 -0800 (PST) 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:content-type; bh=NccGitOrfiifnE2u2pXO9PPO/EwQ6UHyvY1/L+O3DV0=; b=EbUvwCJibDQre24Mmr5jo+hZCBxNjMCTYtkw/DTodGuNfPX071m0BqA4ookQiN44tj xxxqQ/so3Qxz65WnCqD0mdrPreP7UnZZM4eMgIt2YeoeiMP6tEgmuB/uzileYJgsQfae chj9yGdQ+z3pDgMy694CjbtEDqKqo1f0/QxWKyHSzlg9Q5OEmiMoHH+vUqkZ2dDGHrsy LBB/i17zxQCtgBFvJODjQe8uEZ3NdLe0cgbnEciEtM/0kVMk9CdGzQhmwV85yqoK0PQP RnOy1N1B1h1Dnagcv0jQNxHTVgFATkoZFd0GY+hi6gnhR+HgZFCpLB7InuuhMZNFV8qn 7oDw== 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:content-type; bh=NccGitOrfiifnE2u2pXO9PPO/EwQ6UHyvY1/L+O3DV0=; b=UijVl9EjhA1cUoOJgT/Zx3Gg7KHweYB4tiCoLT+DJbYyMke8YCl/cHUWnvFvaRgMYa YkwfWyQiLs/VdboEeTueE+YbQ0JdOeGaM3VvNXXos0jkrWZpUw0ua6SAYzAi0bmDx53W CeY+6TtpHQ5duXg0siOODSZqD2SAJkwOKrU3CdI+DRbiKcgE1GmuyyfeiLMEJwEpsWwI cHfPNiLhQFg5PAb2H24lNkPKX3sCNcX7RC9mAg72MhanD2ZtvPZS0Cyp5P7dEh6ZJVRQ Pinyw0ELgTtO1nm+wXdz3OfCW0Dff/7rAcTmLK4k4SyWj4uRQG1UhnneoaKs6MrOxIFn 2hQQ== X-Gm-Message-State: ALoCoQlbrnT7RyIX7rEzD/WF2rm51o3wtO1qawPQMdUayv25trKarjZW+Ed9YyUcQcqCmCEhlE+e MIME-Version: 1.0 X-Received: by 10.25.35.194 with SMTP id j185mr1211045lfj.62.1447864377105; Wed, 18 Nov 2015 08:32:57 -0800 (PST) Received: by 10.112.144.106 with HTTP; Wed, 18 Nov 2015 08:32:57 -0800 (PST) In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> Date: Wed, 18 Nov 2015 08:32:57 -0800 Message-ID: From: Andy Bierman To: Somaraju Abhinav Content-Type: multipart/alternative; boundary=001a113a9f04e177ba0524d33172 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:33:02 -0000 --001a113a9f04e177ba0524d33172 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav < abhinav.somaraju@tridonic.com> wrote: > Hi Peter, > I like your proposal of starting with the four drafts. Just a few comments > > - Before working through iv) function set, I think it makes a little bit > of time working out what use cases we want to support. In particular, I > think we should decide if we are only going to address Netconf/Restconf > support or if we expect to support Yang application layer module > management. In my opinion, in constrained networks we will not support two > management protocols one for networking and one for application layer. > Therefore, we should support both in the function set. > > We don't know this term "YANG application layer module management" in the NETMOD WG. The semantics of the YANG module can be anything. The same language is used for devices and controllers, as well as application and server code generation by many tools. > - Access control. I think for iv) function set, we should also think about > how access control is going to work while we look at the function set. I > don't know if this is a separate draft in a different WG (e.g. ACE). But > from the perspective of being able to use a device management protocol, > unless we also get interoperability for access control/security mechanisms, > the drafts will not be usable in the field. > Would this be a replacement for NACM, which is how authorization is handled for YANG data. > - Regarding Versions of YANG modules: I do not understand why we need > consistent numbering when a module version gets upgraded. As Rodney already > mentioned, we can not assume that new versions of a module are supersets of > old versions. I think it is also important to keep using the automated > numbering scheme as far as possible. So, my questions is the following: do > we need data node IDs consistent across versions of YANG modules. > > YANG is just like SMIv2 wrt/ permanent identifiers. Once an ID is assigned it is never removed. The 'status' statement is used to manage lifecycle issues like obsolete objects. So you can assume revision N+1 is a superset of N (at least for the purpose of object identification). When a module is updated in the server, we usually attempt to minimize the change such that existing client code will continue to work without an upgrade. This is how YANG Hash works. If the Cool numbers are version-specific, then a client needs to store multiple sets of IDs to work with each version, and also needs to be updated anytime a server it manages is updated. Abhinav > Andy > > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of peter van der Stok [ > stokcons@xs4all.nl] > Sent: Wednesday, November 18, 2015 8:27 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] CoMI Cool draft splits > > > > > I think the YANG Hash draft should be separate from the protocol. > > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > > > > I agree with Andy here. > Although I sympathize with Rodney, that once the four drafts are > reality, the WG should decide about adoption and a recombination of > documents. > > Peter > > _______________________________________________ > 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. > --001a113a9f04e177ba0524d33172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav &l= t;abhina= v.somaraju@tridonic.com> wrote:
Hi Peter,
I like your proposal of starting with the four drafts. Just a few comments<= br>
- Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my = opinion, in constrained networks we will not support two management protoco= ls one for networking and one for application layer. Therefore, we should s= upport both in the function set.


We don't know this term "YANG= application layer module management" in the NETMOD WG.
The = semantics of the YANG module can be anything.=C2=A0 The same language is us= ed for devices
and controllers, as well as application and server= code generation by many tools.

=C2=A0
- Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But = from the perspective of being able to use a device management protocol, unl= ess we also get interoperability for access control/security mechanisms, th= e drafts will not be usable in the field.


Would this be a replacement for NACM, which is how author= ization is handled
for YANG data.



- Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numberi= ng scheme as far as possible. So, my questions is the following: do we need= data node IDs consistent across versions of YANG modules.



YANG is just like SMIv2= wrt/ permanent identifiers.
Once an ID is assigned it is never r= emoved.
The 'status' statement is used to manage lifecycl= e issues like obsolete objects.
So you can assume revision N+1 is= a superset of N (at least for the purpose
of object identificati= on).

When a module is updated in the server, we us= ually attempt to minimize the change
such that existing client co= de will continue to work without an upgrade.
This is how YANG Has= h works.=C2=A0 If the Cool numbers are version-specific, then
a c= lient needs to store multiple sets of IDs to work with each version, and al= so
needs to be updated anytime a server it manages is updated.


Abhinav

Andy
=C2=A0

________________________________________
From: core [core-bounces@ietf.org<= /a>] on behalf of peter van der Stok [stokcons@xs4all.nl]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

>
> I think the YANG Hash draft should be separate from the protocol.
> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >

I agree with Andy here.
Although I sympathize with Rodney, that once the four drafts are
reality, the WG should decide about adoption and a recombination of
documents.

Peter

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ 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= responsibility for viruses and it is your responsibility to scan or otherw= ise check this e-mail and any attachments.

--001a113a9f04e177ba0524d33172-- From nobody Wed Nov 18 08:37:13 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1F1A1BD4 for ; Wed, 18 Nov 2015 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec3cLWlDKD4S for ; Wed, 18 Nov 2015 08:37:09 -0800 (PST) Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003121A1B96 for ; Wed, 18 Nov 2015 08:37:07 -0800 (PST) Received: from unknown (HELO NOKWDCFIEXCH02P.nnok.nokia.com) ([10.50.38.50]) by noi-msg-2.service.capgemini.fi with ESMTP; 18 Nov 2015 18:37:05 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 18 Nov 2015 18:37:04 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.1044.021; Wed, 18 Nov 2015 18:37:04 +0200 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: EXT Cullen Jennings , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Thread-Topic: SemML time series data representation? Thread-Index: AdEiHUZ1breKcyk1Qzq1U/mXRYRdgQ== Date: Wed, 18 Nov 2015 16:37:03 +0000 Message-ID: <1d3a2378c7df499e84f3edae6f5d1f96@NOKWDCFIEXCH02P.nnok.nokia.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.50.32.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-jennings-core-senml@tools.ietf.org" , core Subject: [core] SemML time series data representation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:37:12 -0000 SGksDQoNCkkndmUgbm90IGZvbGxvd2VkIENPUkUgb3IgU2VuTUwgZGlzY3Vzc2lvbnMgZm9yIGEg d2hpbGUsIHNvIGFwb2xvZ2llcyBpZiB0aGlzIGEgRkFRLiBJIG5vdGljZWQgdGhlcmUgaXMgYSBk aXNjdXNzaW9uIGFib3V0IFNlbk1MIHN0cmVhbWluZyBhbmQgdGhhdCB0cmlnZ2VyZWQgYSBxdWVz dGlvbiByZWxhdGVkIHRvIGEgcHJvamVjdCBJJ20gd29ya2luZyBvbi4gQmFzaWNhbGx5IEkgd291 bGQgbGlrZSB0byBzZW5kIGEgbGFyZ2UgbnVtYmVyIG9mIHNlbnNvciByZWFkaW5ncyB0aGF0IGhh dmUgYmVlbiBtZWFzdXJlZCB3aXRoIGEgY29uc3RhbnQgc2FtcGxlIHJhdGUuIFRoaXMgY291bGQg YmUgZXZlbiB0ZW5zIG9mIHRob3VzYW5kcyBvZiBzYW1wbGVzIGF0IGEgdGltZS4gSW4gU2VuTUws IGlzIHRoZXJlIGFueSByZWFzb25hYmxlIHdheSB0byByZXByZXNlbnQgdGhpcyB0eXBlIG9mIHRp bWUgc2VyaWVzIGluIGEgY29tcGFjdCBtYW5uZXI/IEluIHRoZSBkcmFmdCBJIHNlZSB0aGlzIGtp bmQgb2YgZXhhbXBsZToNCg0KICAgW3siYm4iOiAidXJuOmRldjptYWM6MDAyNGJlZmZmZTgwNGZm MS8iLA0KICAgICAiYnQiOiAxMjc2MDIwMDc2LA0KICAgICAiYnUiOiAiQSIsDQogICAgICJ2ZXIi OiAxfSwNCiAgICBbIHsgIm4iOiAidm9sdGFnZSIsICJ1IjogIlYiLCAidiI6IDEyMC4xIH0sDQog ICAgICB7ICJuIjogImN1cnJlbnQiLCAidCI6IC01LCAidiI6IDEuMiB9LA0KICAgICAgeyAibiI6 ICJjdXJyZW50IiwgInQiOiAtNCwgInYiOiAxLjMwIH0sDQogICAgICB7ICJuIjogImN1cnJlbnQi LCAidCI6IC0zLCAidiI6IDAuMTRlMSB9LA0KICAgICAgeyAibiI6ICJjdXJyZW50IiwgInQiOiAt MiwgInYiOiAxLjUgfSwNCiAgICAgIHsgIm4iOiAiY3VycmVudCIsICJ0IjogLTEsICJ2IjogMS42 IH0sDQogICAgICB7ICJuIjogImN1cnJlbnQiLCAidCI6IDAsICAidiI6IDEuNyB9IF0NCiAgIF0N Cg0KVGhpcyBraW5kIG9mIHdvcmtzIGJ1dCBpdCB3b3VsZCBiZSBxdWl0ZSByZWR1bmRhbnQgdG8g bGl0ZXJhbGx5IHNlbmQgICAibiI6ImN1cnJlbnQiLCJ0IjpOLCAidiI6ICAgdGVuIHRob3VzYW5k IHRpbWVzLiBUaGUgY3VycmVudCBmb3JtYXQgd2UgYXJlIHVzaW5nIGhhcyBhZGRpdGlvbmFsIG1l dGFkYXRhIHN1Y2ggYXMgc2FtcGxlIHJhdGUgKG9yIHNhbXBsZSBpbnRlcnZhbCksIGFuZCBhbHNv IHRoZSBtZWFzdXJlbWVudCB0eXBlIGFuZCB0aGUgbWVhc3VyZW1lbnQgdW5pdCBjYW4gYmUgZ2l2 ZW4gb25seSBvbmNlLiBUaGlzIG1lYW5zIHdlIGNhbiBqdXN0IHNlbmQgYW4gYXJyYXkgb2YgYWN0 dWFsIG1lYXN1cmVtZW50IHJlc3VsdHMgb2YgdGhlIHNhbWUgdHlwZSBhbmQgc2FtcGxlIGludGVy dmFsLCBlLmcuIFsxLjIsIDEuMzAsIDAuMTRlMSwgMS41LCAxLjYsIDEuN10sIGluIGEgY29tcGFj dCBtYW5uZXIuDQoNCklzIHRoaXMgcG9zc2libGUgaW4gU2VuTUw/IFdvdWxkIHNlZW0gbGlrZSBh IHVzZWZ1bCBmZWF0dXJlIGZvciBtYW55IHB1cnBvc2VzIHdoZXJlIHNlbnNvcnMgcmVwb3J0IGRh dGEgaW4gYmF0Y2hlcy4gDQoNCk1hcmt1cyANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRVhUIEN1bGxlbiBKZW5uaW5ncw0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE4LCAy MDE1IDQ6MTUgQU0NCj4gVG86IENocmlzdGlhbiBBbXPDvHNzIDxjLmFtc3Vlc3NAZW5lcmd5aGFy dmVzdGluZy5hdD4NCj4gQ2M6IGRyYWZ0LWplbm5pbmdzLWNvcmUtc2VubWxAdG9vbHMuaWV0Zi5v cmc7IGNvcmUgPGNvcmVAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gU2VuTUwgSlNP TiBzeW50YXggYW5kIGNvbGxlY3Rpb24rc2VubWwranNvbg0KPiANCj4gDQo+IFJhbmRvbSB0aG91 Z2h0cyBvbiBhICBmZXcgc3ViamVjdHM6DQo+IA0KPiBJIGZlZWwgbGlrZSBTZW5NTCBpcyBnZXR0 aW5nIHRvIGNvbXBsZXggYW5kIHdlIHNob3VsZCBhc2sgaWYgd2UgY2FuIHB1dCBpdCBvbiBhDQo+ IGRpZXQuIFBlcmhhcHMgdGhpcyBzdHJlYW1pbmcgaXMganVzdCB0b28gbXVjaCB0byBwdXQgaW50 byBpdC4gQW4gYWx0ZXJuYXRpdmUgaXMgdG8NCj4gbm90IGhhdmUgU2VuTUwgZG8gc3RyZWFtaW5n IGJ1dCBhbGxvdyBhIHByb3RvY29sIHVzaW5nIGl0IHRvIHN1cHBvcnQNCj4gc3RlYW1pbmcgYnkg c2VuZGluZyBtYW55IFNlbk1MIG9iamVjdHMgd2l0aCB0aGUgY29udmVudGlvbiB0aGF0IGlzIGFu eQ0KPiBnaXZlbiBvYmplY3QgZGlkIG5vdCBoYXZlIGEgYmFzZSB2YWx1ZSwgdGhlbiB0aGUgYmFz ZSB2YWx1ZXMgZnJvbSB0aGUNCj4gcHJldmlvdXMgU0VOTUwgb2JqZWN0IGFwcGxpZWQuIEknbSBu b3Qgc3VyZSBpZiB0aGlzIGlzIGEgZ29vZCBpZGVhIG9yIG5vdCBidXQNCj4gSSdtIGp1c3Qgc2F5 aW5nIHRoYXQgaWYgdGhpbmdzIHN0YXJ0IHRvIGdldCB0b28gY29tcGxpY2F0ZWQgdG8gZG8gc3Ry ZWFtaW5nDQo+IGluc2lkZSBTZW5NTCwgd2UgY2FuIHB1bnQgaXQgdXAgYSBsYXllci4NCj4gDQo+ IA0KPiBDb21wbGV4aXR5IDoNCj4gDQo+IEknbSBzdXJlIHNvbWVvbmUgd2lsbCB0aGluayBJIGFt IG51dHMgZm9yIHN1Z2dlc3RpbmcgdGhhdCBTZW5NTCBpcyBsb29raW5nDQo+IHRvbyBjb21wbGlj YXRlZCBidXQgYXMgYW5vdGhlciBleGFtcGxlIC4uLiB0YWtlIEluZmx1eERCIHdoaWNoIGlzIHBy ZXR0eQ0KPiBnb29kIGZvciBzdHVmZiBsaWtlIHRoaXMuIEl2ZSBiZWVuIHVzaW5nIGl0IGZvciBh IGNsb3VkIERCIGZvciBzdHJlYW1pbmcgUlQNCj4gbWVhc3VyZW1lbnRzLiBJdCBkZXByZWNhdGVk IEpTT04gYW5kIHJlcGxhY2VkIGl0IHdpdGggIkxpbmUgUHJvdG9jb2wiDQo+IHdoaWNoIGlzIGVm ZmVjdGl2ZWx5IHRoZSBzZW5zb3IgbmFtZSBmb2xsb3dlZCBieSBzcGFjZSBzZXBhcmF0ZWQgIGZv bGxvd2VkDQo+IGJ5IHRoZSB2YWx1ZSBmb2xsb3dlZCBieSBDUkxGLiBUaGF0IHByb2R1Y2VkIG5v dGljZWFibGUgaW1wcm92ZW1lbnRzIGluDQo+IHJlYWwgZGVwbG95bWVudHMgb3ZlciBnZW5lcmFs IEpTT04uIEEgYmlnIHBhcnQgb2YgU2VuTUwgd2FzIHRvICpub3QqIGJlIGJlDQo+IGdlbmVyYWwg SlNPTiBhbmQgYmUgYSB2ZXJ5IHJlc3RyaWN0ZWQgc3Vic2V0IG9mIEpTT04gc3VjaCB0aGF0IGl0 IGNvdWxkDQo+IGFjaGlldmUgdGhlIHBlcmZvcm1hbmNlIG9mIHNvbWV0aGluZyBsaWtlICJMaW5l IFByb3RvY29sIiBvciBwcm90byBidWZzIGFuZA0KPiBzdGlsbCBoYXZlIHNvbWUgZXh0ZW5zaWJp bGl0eSBzdG9yeS4NCj4gDQo+IFNvIExpbmUgUHJvdG9jb2wgd291bGQgc2VuZCB0aGUgZXhhbXBs ZSBmcm9tIGxhdGVyIGluIHRoaXMgZW1haWwgYXMgYSBzaW5nbGUNCj4gbGluZSB3aXRoDQo+IA0K PiB1cm46ZGV2Om1hYzowMDI0YmVmZmZlODA0ZmYxL3ZvbHRhZ2UgdT1WIDEyMC4xDQo+IA0KPiAN Cj4gDQo+IE1ldGFEYXRhOg0KPiANCj4gVGhlIG1vcmUgSSB0aGluayBhYm91dCBtZXRhZGF0YSBh bmQgZGF0YSB0aGUgbGVzcyBJIGtub3cgd2hpY2ggaXMgd2hhdC4NCj4gQ29uc2lkZXINCj4gDQo+ ICBbIHsiYm4iOiAidXJuOmRldjptYWM6MDAyNGJlZmZmZTgwNGZmMS8ifSwNCj4gICAgIFsgeyAi biI6ICJ2b2x0YWdlIiwgInQiOiAwLCAidSI6ICJWIiwgInYiOiAxMjAuMSB9IF0gIF0NCj4gDQo+ IFlvdSBjb3VsZCBhcmd1ZSB0aGUgb25seSB0aGluZyB0aGF0IGlzIG5vdCBtZXRhZGF0YSBpcyAx MjAuMQ0KPiANCj4gSSB0aGluayB0aGUgZ29hbCBvZiBTZW5NTCBpcyB0byBoYXZlIGEgcmVjb3Jk IHRoYXQgaGFzIGEgbWluaW1hbCBzZXQgb2YgaW5mbw0KPiB0aGF0IGlzIG9mdGVuIG5lZWRlZCB0 byBpbnRlcnByZXQgdGhlIGRhdGEgaW4gb25lIHJlY29yZC4gVGhlIGJhc2UgbmFtZXMNCj4gd2Vy ZSBhZGRlZCBtZXJlbHkgYXMgY29tcHJlc3Npb24gc2NoZW1lIHRvIHJlZHVjZSBkdXBsaWNhdGlv biBvZiBzYW1lDQo+IGJpdHMgc2V2ZXJhbCB0aW1lcy4gSSdtIG5vdCByZWFsIHdvdW5kIHVwIGFi b3V0IGl0IHNvbWUgb2YgaXQgaXMgbWV0YSBkYXRhIG9yDQo+IG5vdC4NCj4gDQo+IA0KPiANCj4g U3RyZWFtaW5nOg0KPiANCj4gV2hlbiBJIGZpcnN0IHJlYWQgdGhhdCBsaW5lIHRoYXQgc2FpZCB0 aGUgbGF0ZXN0IFNlbk1MIGRyYWZ0ICJyZXF1aXJlcyBzdXBwb3J0DQo+IG9mIHN0cmVhbWluZyIg SSB0aG91Z2h0IHRoYXQgd2FzIHdyb25nIGJ1dCB0aGUgbW9yZSBJIHRob3VnaHQgYWJvdXQgaXQs IHllcywNCj4gSSB0aGluayB0aGlzIGlzIGEgdmVyeSBzZXJpb3VzIHByb2JsZW0gd2l0aCB0aGUg Y3VycmVudCBwcm9wb3NhbC4gSSB3YXMgdGhpbmtpbmcNCj4gYWJvdXQgc2Vuc29yIGRhdGEgYmVp bmcgc2VuZCBmcm9tIGEgc21hbGwgZGV2aWNlIHRvIGEgYmlnIGNsb3VkIGRldmljZSBhbmQNCj4g dGhpcyBtaWdodCB3b3JrIE9LIGJ1dCBpbiB0aGUgY2FzZSBvZiBkYXRhIGdvaW5nIHRvIGFub3Ro ZXIgc21hbGwgZGV2aWNlLCB0aGlzDQo+IGlzIGEgcHJvYmxlbS4gSXQgZG9lcyBoaWdobGlnaHQg dGhlIHByb2JsZW0gb2YgbWF4IHNpemUgZm9yIGEgU2VuTUwgZGF0YS4NCj4gDQo+IFBlcmhhcHMg d2UgbmVlZCB0d28gZGlmZmVyZW50IGZvcm1hdHMgLSBhIFNlbk1MIG9iamVjdCBhbmQgYSBTZW5N TA0KPiBzdHJlYW0uIFRoYXQgd291bGQgYWxsb3cgcHJvdG9jb2xzIHRoYXQgdXNlZCB0aGlzIHRv IGJlIGNsZWFyIGFib3V0IGlmIHRoZXkNCj4gdXNlZCBvbmUgb3IgdGhlIG90aGVyIG9yIGJvdGgg YW5kIHdpdGggSFRUUCBvciBDb0FQLCB0aGUgbm9ybWFsDQo+IGFwcHJvYWNoZXMgY291bGQgYmUg dXNlZCB0byBuZWdvdGlhdGUgdGhlbS4NCj4gDQo+IA0KPiANCj4gPiBPbiBOb3YgMTcsIDIwMTUs IGF0IDM6NDQgUE0sIENocmlzdGlhbiBBbXPDvHNzDQo+IDxjLmFtc3Vlc3NAZW5lcmd5aGFydmVz dGluZy5hdD4gd3JvdGU6DQo+ID4NCj4gPiBIZWxsbyBNaWNoYWVsLA0KPiA+IGhlbGxvIFNlbk1M IGFuZCBjb3JlLWludGVyZmFjZXMgcGVvcGxlLA0KPiA+DQo+ID4gSSdkIGxpa2UgdG8gcGljayB1 cCB0aGUgdG9waWMgb2Ygc3RyZWFtYWJsZSBTZW5NTCBmcm9tIHRoZSBjb250ZXh0IG9mDQo+ID4g dGhlIGBTZW5NTCBKU09OIHN5bnRheGAgc3ludGF4IHRocmVhZCBmcm9tIGJlZm9yZSBJRVRGOTQu DQo+ID4NCj4gPiBUbyBzdW1tYXJpemUgd2hhdCBJIGtub3cgb2YgdGhlIHN0YXRlIG9mIHRoaW5n czoNCj4gPg0KPiA+ICogSlNPTiBTZW5NTCBjYW4ndCBlbmZvcmNlIHRoYXQgdGhlIGJhc2Uge25h bWUsIHRpbWV9IGVudHJpZXMgcHJlY2VkZQ0KPiA+IHRoZSBlbnRyaWVzIGxpc3Qgd2hpbGUgc3Rp bGwgYmVpbmcgSlNPTi4gVG8gcGFyc2UgYSBnZW5lcmljIFNlbk1MDQo+ID4gbWVzc2FnZSwgaXQg aXMgdGh1cyByZXF1aXJlZCB0byBrZWVwIHRoZSB3aG9sZSBtZXNzYWdlIGluIG1lbW9yeS4NCj4g Pg0KPiA+ICBBbiBhbHRlcm5hdGl2ZSBzeW50YXggaXMgcHJvcG9zZWQgW3tiYXNlIGRpY3R9LCBb ZW50cmllc11dOyB0aGF0IGNhbg0KPiA+IGJlIGV4dGVuZGVkIHRvIGFsbG93IHJlcGV0aXRpb25z IHRoZXJlb2YgKHdpdGggaW5jcmVtZW50YWwgYmFzZQ0KPiA+IHZhbHVlcyksIG9yIHRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIGJhc2UgYW5kIGVudHJ5IGRhdGEgY291bGQgYmUNCj4gPiBsaWZ0ZWQg ZnVydGhlci4NCj4gPg0KPiA+ICBUaGlzIGFzc3VtZXMgdGhhdCB0aGUgImUiIHJlY29yZCBsaXN0 IHRha2VzIGEgc3BlY2lhbCByb2xlIGluIFNlbk1MDQo+ID4gYnkgIGJlaW5nIHRoZSB3b3JraG9y c2UgbGlzdCBvZiBkYXRhLCB3aGljaCBjb25mbGljdHMgd2l0aDoNCj4gPg0KPiA+ICogQ29SRSBp bnRlcmZhY2VzIHNlcnZlcyBjb2xsZWN0aW9ucyBhcyBib3RoIGRhdGEgYW5kIG1ldGFkYXRhIGlu IGENCj4gPiB1bmlmaWVkIFNlbk1MIHN0cnVjdHVyZSwgd2hlcmUgcmVzb3VyY2Ugc3RhdGVzIGFy ZSBnaXZlbiBpbiB0aGUNCj4gPiBjbGFzc2ljYWwgImUiIGFycmF5LCBhbmQgdGhlIG1ldGFkYXRh IG5leHQgdG8gaXQgaW4gYW4gImwiIGFycmF5IGFzIGluDQo+ID4gYXBwbGljYXRpb24vbGluay1m b3JtYXQranNvbi4NCj4gPg0KPiA+IEEgbm90YXRpb24gZm9yIHRyZWF0aW5nIHRoZSAibCIgYXJy YXkgYXMgYW4gImUiIGVsZW1lbnQgd2FzIHByb3Bvc2VkLA0KPiA+IGJ1dCBkaWQgbm90IHJlc29u YXRlIHdlbGwgd2l0aCBNaWNoYWVsIChmcm9tIHRoZSBDb1JFIGludGVyZmFjZSBzaWRlKTsNCj4g PiBJJ2QgbGlrZSB0byB0YWtlIHVwIHRoZSBsaW5lIG9mIGRpc2N1c3Npb24gZnJvbSB0aGVyZToN Cj4gPg0KPiA+IE9uIFR1ZSwgT2N0IDIwLCAyMDE1IGF0IDEyOjUyOjE5UE0gLTA3MDAsIE1pY2hh ZWwgS29zdGVyIHdyb3RlOg0KPiA+PiBJdOKAmXMgbW9yZSB0aGFuIGEgc2ltcGxlIHZpc3VhbCBy ZWxhdGlvbnNoaXAuIEnigJltIHVzZWQgdG8gSlNPTiB0b29scw0KPiA+PiB0aGF0IGNyZWF0ZSBh biBpbi1tZW1vcnkgZGF0YSBzdHJ1Y3R1cmUgdGhhdCBjb25mb3JtcyB0byB0aGUgSlNPTg0KPiA+ PiBzZXJpYWxpemF0aW9uLiBXaXRoIHRoZSDigJxvbGTigJ0gU2VuTUwgbW9kZWwsIHRoZSBlbGVt ZW50cyBvZiB0aGUgb2JqZWN0DQo+ID4+IGlkZW50aWZpZWQgYnkg4oCcYm7igJ0gYXJlIHJlbmRl cmVkIGFzIGFuIGFycmF5IHdpdGhpbiB0aGUgZWxlbWVudA0KPiA+PiBpZGVudGlmaWVkIGJ5IOKA nGJu4oCdIGFuZCB0YWdnZWQgYnkg4oCcZeKAnS4NCj4gPj4NCj4gPj4gVGhlIG5ldyBjb25zdHJ1 Y3QgbW9yZSB0aGFuIGp1c3QgZW5hYmxlcyBzdHJlYW1pbmcsIGl0IGZvcmNlcyBzZXJpYWwNCj4g Pj4gaW50ZXJwcmV0YXRpb24sIGkuZS4gaXQgKnJlcXVpcmVzKiBzdHJlYW1pbmcuDQo+ID4NCj4g PiBZZXMsIGFuZCB0aGF0J3MgdGhlIHZlcnkgcG9pbnQuIElmIEknbSB0byBwYXJzZSBTZW5NTCBv biBhIGNvbnN0cmFpbmVkDQo+ID4gZGV2aWNlLCBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgdGhlIHNl bmRlciBjYW4gdXNlIGl0cyBleHRlbnNpYmlsaXR5IHRvDQo+ID4gc2VuZCBhbG9uZyBkYXRhIHRo YXQgaXMgbm90IGV4cGVjdGVkIGJ5IHRoZSByZWNlaXZlciwgdGhhdCBtZWFucyB0aGF0DQo+ID4g SSBuZWVkIHRvIGJlIHByZXBhcmVkIHRvIHN0b3JlIHdoaWNoZXZlciBsZW5ndGggdGhlIGNvbXBs ZXRlIG1lc3NhZ2UNCj4gaGFzLg0KPiA+DQo+ID4gRm9yIGFuIGV4YW1wbGUgb2YgYSBzaXR1YXRp b24gd2hlbiB0aGlzIGNhbiBiZSBhbiBpc3N1ZSwgdGFrZSBhbg0KPiA+IHVwZGF0ZSB0byBhIERN WCAoUkdCIHNwb3RzIG9yIG90aGVyIGxpZ2h0IGluc3RhbGxhdGlvbnMpIGNvbnRyb2xsZXIuIEEN Cj4gPiBQVVQgdG8gYXRvbWljYWxseSB1cGRhdGUgdGhlIGNvbXBsZXRlIHNjZW5lIG9mIGNvbm5l Y3RlZCBkZXZpY2VzIGluDQo+ID4gSlNPTiBzZXJpYWxpemF0aW9uIGNhbiBlYXNpbHkgdGFrZSB1 cCAxMGsgcGx1cyBuZXR3b3JrIG92ZXJoZWFkIGluDQo+ID4gbmV0d29yayBidWZmZXIgc3BhY2Ug ZXZlbiB3aXRob3V0IGFueSBhZGRpdGlvbmFsIG1ldGFkYXRhIGZyb20gU2VuTUwNCj4gPiBleHRl bnNpb25zLCBidXQgKGlmIHJlYWQgaW4gYSBzZXJpYWxpemFibGUgd2F5KSBpbXBsZW1lbnRhdGlv bnMgY291bGQNCj4gPiBnZXQgYXdheSB3aXRoIGEgc2luZ2xlLU1UVS1idWZmZXIgbmV0d29yayBp bXBsZW1lbnRhdGlvbiBwbHVzIDFrIGZvcg0KPiA+IGRvdWJsZS1idWZmZXJlZCBzdGF0ZS4NCj4g Pg0KPiA+IEFub3RoZXIgZXhhbXBsZSAoZnJvbSBteSBldmVyeWRheSBDb0FQIGNvbW11bmljYXRp b24sIGJ1dCBub3QNCj4gPiBpbnZvbHZpbmcgZW1iZWRkZWQgcGFyc2luZykgYXJlIGhpc3Rvcnkg cmVhZG91dHMgb2Ygc2Vuc29yIHZhbHVlcywNCj4gPiB3aGljaCBjYW4gZXhjZWVkIDEwMGtCIGZv ciBkZXZpY2VzIHdpdGggaW50ZXJtaXR0ZW50IG5ldHdvcmsNCj4gY29ubmVjdGl2aXR5Lg0KPiA+ DQo+ID4+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gY3JlYXRlIGEgbmV3IGNvbnRlbnQtZm9ybWF0 IHRoYXQgb3B0aW1pemVzIGZvcg0KPiA+PiBzdHJlYW1pbmcgcHJvY2Vzc2luZz8NCj4gPg0KPiA+ IFRoaXMgaXMgbm90IGFib3V0IHN0cmVhbWluZyBCaWcgRGF0YSBhcm91bmQgdG8gdGhlIHBvaW50 IHdoZXJlIGJpZw0KPiA+IGRldmljZXMgbmVlZCB0byBnbyBpbnRvICJzdHJlYW1pbmcgbW9kZSIg KHRob3VnaCBpdCdzIHVzZWZ1bCB0aGVyZQ0KPiA+IHRvbyksIHRoaXMgaXMgYWJvdXQgKG5vdCB0 aGUgbW9zdCBjb21tb24sIGJ1dCBzdGlsbCByZWxhdGl2ZWx5KSBub3JtYWwNCj4gPiBzaXR1YXRp b25zIGFuZCBub3QgcmV0dXJuaW5nIDQuMTMgZnJvbSBzbWFsbCBkZXZpY2VzIGFueSB0aW1lIHNv bWVvbmUNCj4gPiBkb2Vzbid0IGNodW5rIHVwIGhpcyByZXF1ZXN0IHRvIHNtYWxsIG11bHRpcGxl cyBvZiB0aGUgTVRVLg0KPiA+DQo+ID4gSSBkb24ndCBsaWtlIHRvIGV4YWdnZXJhdGUsIHNvIHBs ZWFzZSB0YWtlIHRoaXMgd2l0aCBhIGdyYWluIG9mIHNhbHQNCj4gPiBhbmQgYXdhcmUgdGhhdCB0 aGlzIGlzIHdyaXR0ZW4gaW4gdGhlIGhlYXQgb2YgdGhlIGFyZ3VtZW50OiBJZiB3ZQ0KPiA+IGRv bid0IGZpbmQgYW4gYWdyZWVhYmxlIHNlcmlhbGl6YXRpb24gdGhhdCBjYW4gYmUgcHJvY2Vzc2Vk IGluIGENCj4gPiBzdHJlYW1pbmcgZmFzaGlvbiwgd2UgbWlnaHQgcmlnaHQgYXMgd2VsbCBwdXQg YSBoYXJkIGxpbWl0IHRvIHRoZQ0KPiA+IG1heGltdW0gc2l6ZSBvZiBhIFNlbk1MIHJlcHJlc2Vu dGF0aW9uLCB0aGF0IGFyZSBhIHJlcXVpcmVkIG1pbmltdW0NCj4gPiBmb3IgU2VuTUwgaW1wbGVt ZW50b3JzIHRvIHN1cHBvcnQuIFdoYXQgd291bGQgdGhhdCBiZSwgNGs/IDE2az8NCj4gPg0KPiA+ Pj4gSW4gbXkgb3BpbmlvbiwgaXQgcmFpc2VzIHRoZSBxdWVzdGlvbiBvZiBob3cgZ2VuZXJpYyBT ZW5NTCBzaG91bGQNCj4gPj4+IGF0dGVtcHQgdG8gYmUuIE15IHBlcnNvbmFsIHZpZXcgb2YgaXQg aXMgdGhhdCBTZW5NTCBpcyBhIHdheSBvZg0KPiA+Pj4gZW5jYXBzdWxhdGluZyBzZXZlcmFsIHJl c291cmNlIHJlcHJlc2VudGF0aW9ucyAoYmUgdGhleSBvZiBkaWZmZXJlbnQNCj4gPj4+IHBvaW50 cyBpbiB0aW1lIG9yIGRpZmZlcmVudCByZXNvdXJjZSkgaW4gYSBzaW5nbGUgbWVzc2FnZS4gV2l0 aCB0aGF0DQo+ID4+PiBpbiBtaW5kLCBtYXliZSB0aGUgZm9sbG93aW5nIHdvdWxkIHdvcmsgZm9y IHlvdSAocmVwaHJhc2luZyB5b3VyDQo+ID4+PiBleGFtcGxlIGludG8gc2VubWwtMDIgc3ludGF4 LCB3aXRoIGNvbW1lbnRzKToNCj4gPj4NCj4gPj4gU2VuTUwgaXMgYWxyZWFkeSBiZWluZyB1c2Vk IHRvIHJlcHJlc2VudCBzaW1wbGUgY29sbGVjdGlvbnMgaW4gQ29SRQ0KPiA+PiBJbnRlcmZhY2Vz LCBPTUEgTFdNMk0sIGFuZCBPSUMuIFdoZXRoZXIgdG8gaGF2ZSBpdCBiZSBleHRlbnNpYmxlIGFu ZA0KPiA+PiBldm9sdmFibGUgb3Igbm90IGlzIGNlcnRhaW5seSBhIHRyYWRlb2ZmIGFnYWluc3Qg Y29tcGxleGl0eSBhbmQNCj4gPj4gc3RyZWFtIHByb2Nlc3NpbmcgYWJpbGl0eS4gSSB3b3VsZCBs ZWFuIHRvd2FyZCBldm9sdmFiaWxpdHkuDQo+ID4NCj4gPiBDb25jZXJuaW5nIGV2b2x2YWJpbGl0 eToNCj4gPg0KPiA+IFRoYXQgc2hvdWxkbid0IGJlIGEgc2hvdyBzdG9wcGVyOiBleHRlbnNpb25z IGNhbiBzdGlsbCBnbyBib3RoIGluIHRoZQ0KPiA+IGJhc2UgZGljdGlvbmFyeSBhbmQgaW4gdGhl IGV2ZW50czsgaXQncyBqdXN0IHRoZXkgd291bGRuJ3QgcHJvZml0IGZyb20NCj4gPiB0aGUgZ3Vh cmFudGVlZCBzZXF1ZW5jZS4NCj4gPg0KPiA+IEFuIGFwcHJvYWNoIEkgZG9uJ3QgbGlrZSBpbiBp dHMgY3VycmVudCBmb3JtIGJ1dCB0aGF0IGNvdWxkIHBvaW50IHRoZQ0KPiA+IGRpcmVjdGlvbiBm b3Igc29tZXRoaW5nIG1vcmUgZWxlZ2FudCBpcyB0byBpbmRpY2F0ZSB0aGUgImtleSIgb2YNCj4g PiBzdWJzZXF1ZW50IGxpc3RzIGluIHRoZSBiYXNlIGRpY3Rpb25hcnk7IHdpdGggeW91ciAibCIg ZXhhbXBsZSwgdGhhdA0KPiA+IGNvdWxkIGJlDQo+ID4NCj4gPiAgICBbIHsiYm4iOiAiL2NvbGxl Y3Rpb24xLyIsICJuZXh0LW9iamVjdCI6ICJlIn0sDQo+ID4gICAgICBbeyJuIjogIml0ZW0xIiwg InN2IjogInZhbHVlMSJ9LCAuLi5dLA0KPiA+ICAgICAgeyJuZXh0LW9iamVjdCI6ICJsIn0sDQo+ ID4gICAgICBbeyJocmVmIjogIml0ZW0xIiwgLi4ufSwgLi4ufQ0KPiA+ICAgIF0NCj4gPg0KPiA+ IEFzIHNhaWQsIGl0J3Mgbm90IHByZXR0eSwgbm9yIHdoYXQgSSdkIGVuZG9yc2UgYXMtaXMsIGJ1 dA0KPiA+IGV4dGVuc2liaWxpdHkgYW5kIGVhc3ktdG8tcGFyc2Ugc2VxdWVuY2UgZG9uJ3QgbmVj ZXNzYXJpbHkgY29uZmxpY3QuDQo+ID4NCj4gPiBDb25jZXJuaW5nIGZvY3VzIG9mIFNlbk1MOg0K PiA+DQo+ID4gU2ltcGxlIGNvbGxlY3Rpb25zIHNlZW1zIHRvIGJlIGEgZ29vZCBvdXRsaW5lOyB3 b3VsZCB5b3UgYWxzbyBhZ3JlZSB0bw0KPiA+ICJzaW1wbGUgY29sbGVjdGlvbnMgb2YgcmVzb3Vy Y2UgcmVwcmVzZW50YXRpb25zIGFuZCB0aGVpciBtZXRhZGF0YSI/DQo+ID4NCj4gPj4+IFdoYXQg ZG8geW91IHRoaW5rIG9mIHRoZSBhYm92ZSBhcnJhbmdlbWVudD8NCj4gPj4NCj4gPj4gSSB0aGlu ayBpdOKAmXMgYSBzdWJzdGFudGlhbCBjb21wcm9taXNlIGluIHRoZSBhYmlsaXR5IHRvIHJlcHJl c2VudA0KPiA+PiBkYXRhIHN0cnVjdHVyZSB0byBnZXQgc3RyZWFtaW5nIHByb2Nlc3NpbmcgYWJp bGl0eS4gQnV0IEkgZG8gbGlrZSB0aGUNCj4gPj4gaWRlYSBvZiBhIOKAnG924oCdIGVsZW1lbnQg Zm9yIG9iamVjdCB2YWx1ZXMuDQo+ID4NCj4gPiBEb2VzIHRoYXQgcmVmZXIgdG8gdGhlIG5ldyBz ZXJpYWxpemF0aW9uIGZvcm1hdCBpbiBnZW5lcmFsIG9yIHRvDQo+ID4gcGFja2luZyB0aGUgbGlu ayBsaXN0IGludG8gYW4gZW50aXR5IHJlc3BvbnNlIGluIHBhcnRpY3VsYXI/IEluIHRoZQ0KPiA+ IGxhdHRlciBjYXNlLCBwbGVhc2UgZWxhYm9yYXRlIC0tIHRoZSBsYXR0ZXIgImhhcHBlbmVkIiB3 aXRoIHRoZQ0KPiA+IGluZnJhc3RydWN0dXJlIEkndmUgYmVlbiB1c2luZyAodW5kZXIgY2VydGFp biBjb25kaXRpb25zLCBteSBiYXRjaA0KPiA+IHJlc291cmNlcyBjb250YWluIHRoZWlyIGFwcGxp Y2F0aW9uL2xpbmstZm9ybWF0IGFzICJzIjogZW50cmllcyksIEkndmUNCj4gPiBmb3VuZCBpdCBw cmFjdGljYWwsIGFuZCBpdCB3b3VsZCBjb21lIGluIG11Y2ggbW9yZSBoYW5keSB3aXRoICJvdiI6 bGluay0NCj4gZm9ybWF0K2pzb24uDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMNCj4gPiBDaHJpc3Rp YW4NCj4gPg0KPiA+IC0tDQo+ID4gQ2hyaXN0aWFuIEFtc8O8c3MgICAgICAgICAgICAgICAgICAg ICAgfCBFbmVyZ3kgSGFydmVzdGluZyBTb2x1dGlvbnMgR21iSA0KPiA+IGZvdW5kZXIsIHN5c3Rl bSBhcmNoaXRlY3QgICAgICAgICAgICAgfCBoZWFkcXVhcnRlcjoNCj4gPiBtYWlsdG86Yy5hbXN1 ZXNzQGVuZXJneWhhcnZlc3RpbmcuYXQgIHwgQXJiZWl0ZXJnYXNzZSAxNSwgQS00NDAwIFN0ZXly DQo+ID4gdGVsOis0My02NjQtOTctOTAtNi0zOSAgICAgICAgICAgICAgICB8IGh0dHA6Ly93d3cu ZW5lcmd5aGFydmVzdGluZy5hdC8NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCBBVFU2ODQ3NjYxNA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Wed Nov 18 10:10:02 2015 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 CB1761A0029; Wed, 18 Nov 2015 10:09:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151118180959.18753.10193.idtracker@ietfa.amsl.com> Date: Wed, 18 Nov 2015 10:09:59 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 18:10:00 -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 Working Group 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-00.txt Pages : 12 Date : 2015-11-18 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-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 18 10:15:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5451A1B5A; Wed, 18 Nov 2015 10:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuxwiWd_v6hf; Wed, 18 Nov 2015 10:15:06 -0800 (PST) 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 E180A1A1B40; Wed, 18 Nov 2015 10:15:05 -0800 (PST) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id E9CE6C5A67; Wed, 18 Nov 2015 19:15:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lvC4wO_1gvOU; Wed, 18 Nov 2015 19:15:02 +0100 (CET) X-Originating-IP: 88.128.80.244 Received: from nar.railnet.train (unknown [88.128.80.244]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 0432CC5A72; Wed, 18 Nov 2015 19:14:58 +0100 (CET) Message-ID: <564CC021.1090301@tzi.org> Date: Wed, 18 Nov 2015 19:14:57 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Andrew Mcgregor 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 , draft-tschofenig-core-coap-tcp-tls@ietf.org Subject: Re: [core] Call for adoption of draft-tschofenig-core-coap-tcp-tls X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 18:15:08 -0000 Done (with minimal editorial changes only). Reminder: The two editorial notes still remaining are: -- what are our recommendations about when the capability to send larger messages (than reasonable over UDP/DTLS) should actually be used, and -- should we always set ALPN or only on port 443? We would appreciate input on how to resolve these; this should then make the document ready for WGLC. Gr眉脽e, Carsten Andrew Mcgregor wrote: > And it looks like we have pretty good consensus from the list as well. > > Authors, please submit your next version as a WG draft under the > name draft-ietf-core-coap-tcp-tls. > > On 3 November 2015 at 15:38, Andrew Mcgregor > wrote: > > The sense of the room at IETF 94 was that we should adopt this as a > working group document. > > This is the corresponding mailing list call, open until November 16. > > Title : A TCP and TLS Transport for the > Constrained Application Protocol (CoAP) > Authors : Carsten Bormann > Simon Lemay > Valik Solorzano Barboza > Hannes Tschofenig > Filename : draft-tschofenig-core-coap-tcp-tls-05.txt > Pages : 12 > Date : 2015-11-02 > > 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-tschofenig-core-coap-tcp-tls/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-tschofenig-core-coap-tcp-tls-05 > > -- > Andrew McGregor | SRE | andrewmcgr@google.com > | +61 4 1071 2221 > > > > > -- > Andrew McGregor | SRE | andrewmcgr@google.com > | +61 4 1071 2221 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Nov 18 12:53:08 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FEF1B2EAA for ; Wed, 18 Nov 2015 12:53:07 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id homDxIgkylbA for ; Wed, 18 Nov 2015 12:53:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50251B2EA4 for ; Wed, 18 Nov 2015 12:53:03 -0800 (PST) Received: from BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) by BLUPR06MB033.namprd06.prod.outlook.com (10.242.191.12) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 18 Nov 2015 20:52:43 +0000 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.325.17; Wed, 18 Nov 2015 20:52:41 +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.0325.019; Wed, 18 Nov 2015 20:52:41 +0000 From: Michel Veillette To: Somaraju Abhinav , "consultancy@vanderstok.org" , Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbWsbLKAGX5UGJtJafdAsAuZ6gXYKAgAAcVgCAAOkigIAAEbYAgADKbCA= Date: Wed, 18 Nov 2015 20:52:41 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> , <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 5:GcFEGwTvjdb0GrGtAOgVBW3KK0NuU9jQcKslMn7ZBz8vL/GoZ5nNikJ6iOCG1/ISr4kKg34hNnu/M1RWJHiD1D+jiH+ieBDoYTWXU9uyTrgtkaFY0Kf+J7KM8xcEYqA3VaIURm5K8PR6F1ZbO9WwcQ==; 24:ef0ECZH5/7UAnAZnO3JOFE7gSz9LMX/gq/b2/K6oGVc0curbb17rD4Ij0dKIVtoT+gEXIhyAgldEs/u/HBlmz+Hb4TKDenrY9XhJ0kHa1CU=; 20:M1iZ4RM5hyB6IuV/d1x2HprqIxKdFOomdNN7nGU5YUZBvJ49iSj6Sc9v9NTC2JhDb4HiLdUdxgpyVQBnFDHQoQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1761; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(262738631018165); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1761; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(57704003)(377454003)(189002)(199003)(122556002)(5001960100002)(76576001)(2501003)(87936001)(92566002)(105586002)(33656002)(97736004)(81156007)(5008740100001)(5003600100002)(5002640100001)(99286002)(5001770100001)(106116001)(5007970100001)(106356001)(5004730100002)(189998001)(11100500001)(40100003)(10400500002)(2900100001)(54356999)(77096005)(93886004)(561944003)(2950100001)(76176999)(74316001)(15975445007)(50986999)(586003)(101416001)(5890100001)(19580405001)(19580395003)(66066001)(86362001)(6116002)(3846002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 20:52:41.5885 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-Microsoft-Exchange-Diagnostics: 1; BLUPR06MB033; 2:hn19iOkXzrDVwQoQSm8kGSo4Z7Ki03R4gqHG2KNVnc1dPTESwRGmqtOmZBdFr8rnhE4VWIOH4Qt4ctJULdIXz2s+VHMAhDoU3eMjE1po9gtZ7qs3CzwHtPHwSJ8JBW4Pwz8GWTi3mEA6ljptMp30HoCpClJ7a0CSkISEHJss/DM=; 23:hsdIupJc/nEfH/WV+bsX3mXImz4UvivnTwqUEf0P9w2n0xmgy4RSVHAM0mZqh9s9ciggTF17sd9f+roYhhhK90Te+YsE6D84xeGKSGdwRza8x5MxIKzTUvjR3+IGDYl5DKS72dQejvcZo2vYsZu/pGneUXhfeRkt+lbtjkbY7ReVu7FcEvlstwQ7komoq0+m X-OriginatorOrg: trilliantinc.com Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:53:07 -0000 Hi Somaraju, Hi Peter =3D=3D=3D About "Access control" I was assuming that this topic will be addressed later but scheduling draft= (s) right now seem appropriate. Typically, there is two approaches to access control: - Centralized using attribute certificate (or equivalent) [RFC 5755] - Distributed using Access Control List (ACL) I propose to add two drafts to address these two items. =3D=3D=3D About "I do not understand why we need consistent numbering when = a module version gets upgraded" I thing that the protocol should support both approaches, backward compatib= le and non backward compatible IDs. It's up to the developers to select the appropriate approach for each speci= fic use case. It's also important to note that the augment YANG statement can be used to = add new functionalities (new data nodes, rpc, notifications) in a very clea= n way without affecting the already automatically generated IDs. I believe = this should be the recommended approach to implement enhancements. Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Somaraju Abhinav Sent: November-18-15 3:31 AM To: consultancy@vanderstok.org; Andy Bierman Cc: Core Subject: Re: [core] CoMI Cool draft splits Hi Peter, I like your proposal of starting with the four drafts. Just a few comments - Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my = opinion, in constrained networks we will not support two management protoco= ls one for networking and one for application layer. Therefore, we should s= upport both in the function set. - Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But from= the perspective of being able to use a device management protocol, unless = we also get interoperability for access control/security mechanisms, the dr= afts will not be usable in the field. - Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numberi= ng scheme as far as possible. So, my questions is the following: do we need= data node IDs consistent across versions of YANG modules. Abhinav ________________________________________ From: core [core-bounces@ietf.org] on behalf of peter van der Stok [stokcon= s@xs4all.nl] Sent: Wednesday, November 18, 2015 8:27 AM To: Andy Bierman Cc: Core Subject: Re: [core] CoMI Cool draft splits > > I think the YANG Hash draft should be separate from the protocol. > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > I agree with Andy here. Although I sympathize with Rodney, that once the four drafts are reality, t= he WG should decide about adoption and a recombination of documents. Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________________________________ 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Wed Nov 18 14:21:51 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631781B30D0 for ; Wed, 18 Nov 2015 14:21:50 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BTqlcJKr9YW for ; Wed, 18 Nov 2015 14:21:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0991B30CA for ; Wed, 18 Nov 2015 14:21:45 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB421.namprd04.prod.outlook.com (10.141.58.143) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 22:21:26 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) with mapi id 15.01.0325.019; Wed, 18 Nov 2015 22:21:26 +0000 From: Rodney Cummings To: Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwteQFUWYBvd0yDLSdmSQn7rZ6gWGHwgAA/jYCAABjhAIAAGvyAgAGLziA= Date: Wed, 18 Nov 2015 22:21:26 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.33] x-microsoft-exchange-diagnostics: 1; BN1PR04MB421; 5:X9yrvAymnf/7e8Q/ewn5HllyUZS70of++UAjJ8dirLmVBPzYq/kmMbFwK1U2zI6vuzTgEFugFZtZjjzJEBPewLpICJEfnCwpSu4uZwapwzrRCOXKBqXLpihNMRLMczU5D3eopBuDfAHzTUkkQpiIig==; 24:5zLcohRuuGskXKeBhJe7caKzpQufd/kwbOs5txbCsE+lr84w9YnMybJptFNimqX7TjQX3YiGOV7W7K43QXQ673hFq9rWxHEoinx3QmMjOjA=; 20:Cfy1Onw6WMvp7jQFCJBnK1tr6r/2xVu092KQOGV1MgvB+zL2GJ7rVXeuI6IqRVc+nlgmd17HkMkLBKI9YL7eT8KsBvN8SIaqHsQUeVYfbYX/bI/LVLiFBfVXtiGJi6rF2B86WziPRwy01R+ZMkAUtP+El4KMrQ5iXwAJhPod60w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB421; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN1PR04MB421; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB421; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(377424004)(24454002)(189002)(92566002)(76176999)(86362001)(93886004)(110136002)(102836003)(6116002)(3846002)(81156007)(74316001)(50986999)(87936001)(54356999)(97736004)(189998001)(101416001)(5001960100002)(105586002)(66066001)(99286002)(106356001)(10400500002)(19580395003)(106116001)(586003)(19580405001)(76576001)(40100003)(5004730100002)(5002640100001)(5007970100001)(2900100001)(5008740100001)(33656002)(2950100001)(122556002)(11100500001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB421; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2015 22:21:26.1415 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB421 Archived-At: Cc: peter van der Stok , Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 22:21:50 -0000 T24gVHVlLCBOb3YgMTcsIDIwMTUgYXQgNDoyNyBQTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb20+IHdyb3RlOg0KPiBZQU5HIGRvZXMgbm90IGFjdHVhbGx5IGFsbG93IG9iamVjdHMg dG8gYmUgcmVtb3ZlZC4NCj4gVGhlIHN0YXR1cyBpcyBhbGxvd2VkIHRvIGNoYW5nZSB0byAib2Jz b2xldGUiLg0KPiBZQU5HIGhhc2ggYW5kIGF1dG9tYXRpYyBudW1iZXJpbmcgd2lsbCBib3RoIGJl IGFibGUNCj4gdG8gInJlbWVtYmVyIiB0aGUgZGVsZXRlZCBvYmplY3QgSURzIHNvIHRoZXkgY2Fu IG5ldmVyIGJlIHJldXNlZC4NCg0KVGhhbmtzIEFuZHkuIFRoaXMgd2FzIG15IG1pc3Rha2UuIEkg d2VudCBiYWNrIGFuZCByZWFkIFJGQzYwMjAgc2VjdGlvbiAxMCAoVXBkYXRpbmcgYSBNb2R1bGUp LCBhbmQgdGhpcyBpcyB2ZXJ5IGNsZWFyLiBOb3cgSSB1bmRlcnN0YW5kIHdoeSB0aGUgbWFudWFs IG1lY2hhbmlzbXMgYXJlIG5lZWRlZC4NCg0KT24gVHVlLCBOb3YgMTcsIDIwMTUgYXQgNDozMCBQ TSwgTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPiB3 cm90ZToNCj4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHByb3Bvc2UgdG8gYXV0b21h dGljYWxseSBnZW5lcmF0ZSBJRHMgYmFzZWQNCj4gb24gdGhlIFlBTkcgZGVmaW5pdGlvbiBmaWxl cyBvZiB0aGUgbW9kdWxlcyBpbXBsZW1lbnRlZCBieSBlYWNoIENvTUkvQ29PTA0KPiBzZXJ2ZXIu IElzIHRoaXMgY29ycmVjdD8NCg0KT2ggbm8uLi4gSSByZWFsaXplIHRoYXQgdGhlIFlBTkcgZmls ZXMgd2lsbCBub3QgYmUgZXhjaGFuZ2VkLiBNeSBtaXN0YWtlIHdhcyByZWxhdGVkIHRvIGFuIGFz c3VtcHRpb24gdGhhdCB0aGUgY2xpZW50IGlzIHJlcXVpcmVkIHRvIGltcGxlbWVudCB0aGUgc2Ft ZSByZXZpc2lvbiB0aGF0IHRoZSBzZXJ2ZXIgaW1wbGVtZW50cy4gQXMgQW5keSBwb2ludGVkIG91 dCwgWUFORyBkb2VzIG5vdCByZXF1aXJlIHRoaXMuIEl0IGlzIHBvc3NpYmxlIGZvciBhIGNsaWVu dCB0byBpbXBsZW1lbnQgcmV2aXNpb24gMjAxMS0wMS0wOSAob3JpZ2luYWwpLCBhbmQgdGhlIHNl cnZlciBpbXBsZW1lbnRzIHJldmlzaW9uIDIwMTUtMDgtMDcgKGVuaGFuY2VkKSwgYW5kIGV2ZXJ5 dGhpbmcgd29ya3MganVzdCBmaW5lIChhc3N1bWluZyBubyBvYnNvbGV0ZSBvYmplY3RzKS4NCg0K Um9kbmV5DQoNCg== From nobody Wed Nov 18 23:45:00 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302901A92B7 for ; Wed, 18 Nov 2015 23:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=2.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryviXLBY6YpM for ; Wed, 18 Nov 2015 23:43:35 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7570C1A92B4 for ; Wed, 18 Nov 2015 23:43:34 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud3.xs4all.net with ESMTP id jKjY1r0024d84Ai01KjYPC; Thu, 19 Nov 2015 08:43:32 +0100 Received: from [2001:983:a264:1:5cbf:6d13:c88d:6742] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Nov 2015 08:43:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 19 Nov 2015 08:43:32 +0100 From: peter van der Stok To: Alexander Pelov Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <564C89C6.40903@ackl.io> References: <82c7667140aeaa28efab31a778a26204@xs4all.nl> <564C89C6.40903@ackl.io> Message-ID: X-Sender: stokcons@xs4all.nl (P2l56B8SiGvttByq+qwGNGgvp1LocfBi) User-Agent: XS4ALL Webmail Archived-At: Cc: Core Subject: Re: [core] Your cool presentation on friday core meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 19 Nov 2015 07:43:38 -0000 Hi Alexander see between and Alexander Pelov schreef op 2015-11-18 15:23: > Hi Peter, > > I'm quite busy these days. I would like to send you a detailed > response, but unfortunately this will be impossible today. > > Please, see in-line for some initial remarks. > > Le 18/11/2015 09:09, peter van der Stok a 茅crit : >> Hi Alexander, >> >> I like to react to your presentation of CoMI during the Friday CoRE >> meeting. That is necessary for me to understand the underlying >> factual discussion. >> >> Your statement 鈥淎 hash clash 5 years down the road can break your >> network鈥 needs some clarification. I interpret that, out of the blue, >> a hash clash can occur and lead to problems in the network. This is >> simply not true. A new hash clash may occur when modules are changed >> and recompiled in a server. At that moment and before the server is >> made operational hash clashes are detected and remedial actions can be >> taken. > One of the specific cases I cited is, when you have your network > running for months, maybe several years, before updating a YANG > module, which leads to hash clash. This leads to unexpected protocol > exchanges (e.g. clash-file loading), unexpected memory allocations > (the clients must learn that some of its servers have these new > clashes, while others have some other clashes, and so forth), bugs > that have not been tested for long time, ... I do not share your concern. hashes are generated before loading of the module, hash clashes are easily verified, and rehashes are also done before loading of the module. The rehash protocol concerns one client and one server and can be tested in isolation. Hash clashes are easily simulated. > >> Your next statement 鈥渉ashes are underspecified鈥 also needs some >> clarification. I understood from you that the remark was motivated by >> the absence of a full-proof process defining the solution of hash >> clashes. Such a process is not necessary to assure inter-operability. >> Once solved, the server returns the unique rehashed values and there >> is no need to specify how the rehash values are reached. Nevertheless, >> the draft suggests that a tilde is prefixed to the YANG name, after >> which it is rehashed. There is a very small probability that the new >> hash clashes with another one. Actually, you said to be afraid that >> the hashing algorithm may continuously generate the same set of >> clashing values independent of the prefix. I have no idea if this is >> true, and do not propose to check it for murmur. > I've though on how to handle this specific question for a long time, > and unfortunately you cannot guarantee that re-hashing will no > guarantee new hash clash. Which could, in turn, generate new clashes. > Each clash leads to two new names that need to be rehashed. > >> >> I agree that for efficiency reasons the same rehash process should be >> followed in all servers such that all servers with the same set of >> module versions arrive at the same rehash values. An approach >> different from rehashing is to assign the lowest not assigned natural >> number to the clashing names in lexicographical order. That will >> generally mean that two colliding names get the values 1 and 2 >> assigned, and very rarely the values 3 and 4 may be used. > > I think that Structured IDs provide a way of handling this in a > reasonable manner. We've already discussed how in a structured ID you > can have hashes. I showed that the problem above (continuous generation of hashes) can be easily avoided. >> >> Last I should like to make a remark about probabilities. The whole >> world around us is based on probabilities. For example, there is a >> finite probability that a fatal fault will occur in an airplane during >> one hour of flight. Or that during digital transmission bits are >> toggled without detection by the checksum. These probabilities are >> calculated and should be smaller than a given probability value. This >> is a well-established engineering practice. Therefore, the clash >> probabilities are calculated in appendix E of the CoMI draft. It shows >> that for the targeted hash size and number of names, the probability >> that more than one clash occurs is 10^-3 smaller than the probability >> of one clash. These are quite small values. >> > What constitutes a "small probability" is a relative question. 10E-3 > is typically considered quite elevated (not to say - unacceptably > high) collision probability. Given that you can have hundreds of > entries, this probability is even worst. Given that each collision > requires re-hashing, which could provoke other collisions, we end up > with a problem I consider to be quite dangerous. Appendix E cites different numbers than you do above. For a server with 1000 hashed YANG names and a hash of 30 bits, the probability of a single clash in a given server is 5*10^-4. That means that in an installation with 2000 servers containing disjunct sets of 1000 YANG names (total of 2 million YANG names), there is on average one server with one clash. There being more than one clash has a probability that is 10^-3 lower. In my opinion these are acceptably low probabilities, because they promise quite small rehash information in the clients (In this case: no rehash or one server with one clash) BTW Andy has hashed all YANG names in all to him known modules and no clash occurred. > >> By the way, by relying on identifier assignment, there is also a >> finite probability that the same identifier is allocated to names on >> different modules (a hidden clash), due to power failures, undetected >> transmission errors, or simply copying mistakes. >> I recommend that in the security section of the identifier assignment >> draft, it is discussed how modules are detected with an identifier >> that has been assigned without going through the registration process. >> > That's a non-issue. I regret that you take this issue so lightly. When there is no SDO that makes YANG name number allocation part of the certification process, YANG module writers are not very motivated to pass through a registry and assign the registered numbers. Consequently, servers may use identical numbers for different YANG objects. This means that the extension of your installation with a server runs the risk of duplicate identifiers. You need a procedure to test this, or at least write text that this a reasonable hazard. > >> Hope this will stimulate further discussion. >> >> Peter > Thanks for the useful remarks. I am glad when we have constructive > discussion. Sorry, for the brevity. > > Best, > Alexander From nobody Thu Nov 19 00:23:47 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64151ACCE6 for ; Thu, 19 Nov 2015 00:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=2.999, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbE25nJyRM58 for ; Thu, 19 Nov 2015 00:22:12 -0800 (PST) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id D4EA31ACCE4 for ; Thu, 19 Nov 2015 00:22:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 9C7FF232066; Thu, 19 Nov 2015 09:22:10 +0100 (CET) Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id i0HpzSa94mJX; Thu, 19 Nov 2015 09:22:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 9FBF6232169; Thu, 19 Nov 2015 09:22:09 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.0 zproxy210.enst-bretagne.fr 9FBF6232169 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-bretagne.eu; s=CFDC2CFA-4654-11E5-AACD-7BCC68B6580D; t=1447921329; bh=yVzMv2u1h4EEJ5giYcYNJ/Li2Sv3eT5Wq9qlbKDwrjg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=Yon2r/+N5QeAM55IYLRI9si5UkttNcTG+ytk1fokSEtkg0UEhMnyV8pV821VU/2pf enqmERJ64sFCDXUbeKjCt6VeVQKilwbDv8lJyhb5MNNk+SNeMWSPCojgnSBomnEino 4g/QnrcKDyaRvDk5S4R+sbyCYbIUjvEXa81Lwwrs= X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x99IGX4pwSSG; Thu, 19 Nov 2015 09:22:09 +0100 (CET) Received: from [10.138.187.203] (unknown [193.54.23.146]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 2D4E7232066; Thu, 19 Nov 2015 09:22:09 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_0D054025-4596-4F6F-98EA-1CA327E64C60" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alexander Pelov In-Reply-To: Date: Thu, 19 Nov 2015 09:22:08 +0100 Message-Id: <161D3A3E-B063-42A1-BF31-03C118847908@telecom-bretagne.eu> References: <82c7667140aeaa28efab31a778a26204@xs4all.nl> <564C89C6.40903@ackl.io> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Core Subject: Re: [core] Your cool presentation on friday core meeting X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 08:22:16 -0000 --Apple-Mail=_0D054025-4596-4F6F-98EA-1CA327E64C60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Peter, Once again, sorry for the brievity. Important remarks to keep in mind: 1) there is a seamless way in which you can include hashes within a = Structured ID (hashes are a subset of structured IDs). 2) hashes are incompressible. Structured IDs are very-well adapted to = compression. As we are working on converging on the CoOL and CoMI approaches, it = seems to me that 1) and 2) allow for a graceful cooperation in this = area. See inline. > Le 19 nov. 2015 =C3=A0 08:43, peter van der Stok = a =C3=A9crit : >=20 > Hi Alexander >=20 > see between and >=20 > Alexander Pelov schreef op 2015-11-18 15:23: >> Hi Peter, >> I'm quite busy these days. I would like to send you a detailed >> response, but unfortunately this will be impossible today. >> Please, see in-line for some initial remarks. >> Le 18/11/2015 09:09, peter van der Stok a =C3=A9crit : >>> Hi Alexander, >>> I like to react to your presentation of CoMI during the Friday CoRE = meeting. That is necessary for me to understand the underlying factual = discussion. >>> Your statement =E2=80=9CA hash clash 5 years down the road can break = your network=E2=80=9D needs some clarification. I interpret that, out of = the blue, a hash clash can occur and lead to problems in the network. = This is simply not true. A new hash clash may occur when modules are = changed and recompiled in a server. At that moment and before the server = is made operational hash clashes are detected and remedial actions can = be taken. >> One of the specific cases I cited is, when you have your network >> running for months, maybe several years, before updating a YANG >> module, which leads to hash clash. This leads to unexpected protocol >> exchanges (e.g. clash-file loading), unexpected memory allocations >> (the clients must learn that some of its servers have these new >> clashes, while others have some other clashes, and so forth), bugs >> that have not been tested for long time, ... >=20 > > I do not share your concern. hashes are generated before loading of = the module, hash clashes are easily verified, and rehashes are also done = before loading of the module. > The rehash protocol concerns one client and one server and can be = tested in isolation. > Hash clashes are easily simulated. > As indicated, the problem is not that your resource-unconstrained, = human-operated compiler will not work flawlessly. It certainly will!=20 The problem is that you have your hundreds of devices, coming from = different manufacturers, working in a given manner, until one day you = update some of them, which provokes all these unseen exchanges = (rehashing), and CAN break your network 5 years down the road. (the = statement of my presentation). The biggest problem is actually thing-to-thing communication. With = hashes you have no rendez-vous points within the hashed space. >>> Your next statement =E2=80=9Chashes are underspecified=E2=80=9D also = needs some clarification. I understood from you that the remark was = motivated by the absence of a full-proof process defining the solution = of hash clashes. Such a process is not necessary to assure = inter-operability. Once solved, the server returns the unique rehashed = values and there is no need to specify how the rehash values are = reached. Nevertheless, the draft suggests that a tilde is prefixed to = the YANG name, after which it is rehashed. There is a very small = probability that the new hash clashes with another one. Actually, you = said to be afraid that the hashing algorithm may continuously generate = the same set of clashing values independent of the prefix. I have no = idea if this is true, and do not propose to check it for murmur. >> I've though on how to handle this specific question for a long time, >> and unfortunately you cannot guarantee that re-hashing will no >> guarantee new hash clash. Which could, in turn, generate new clashes. >> Each clash leads to two new names that need to be rehashed. >>> I agree that for efficiency reasons the same rehash process should = be followed in all servers such that all servers with the same set of = module versions arrive at the same rehash values. An approach different = from rehashing is to assign the lowest not assigned natural number to = the clashing names in lexicographical order. That will generally mean = that two colliding names get the values 1 and 2 assigned, and very = rarely the values 3 and 4 may be used. >> I think that Structured IDs provide a way of handling this in a >> reasonable manner. We've already discussed how in a structured ID you >> can have hashes. > > I showed that the problem above (continuous generation of hashes) can = be easily avoided. The problem is not the generation of hash-free clash-files. I am more = then persuaded that you can do this.=20 The problem is that the collision probability increases. > >>> Last I should like to make a remark about probabilities. The whole = world around us is based on probabilities. For example, there is a = finite probability that a fatal fault will occur in an airplane during = one hour of flight. Or that during digital transmission bits are toggled = without detection by the checksum. These probabilities are calculated = and should be smaller than a given probability value. This is a = well-established engineering practice. Therefore, the clash = probabilities are calculated in appendix E of the CoMI draft. It shows = that for the targeted hash size and number of names, the probability = that more than one clash occurs is 10^-3 smaller than the probability of = one clash. These are quite small values. >> What constitutes a "small probability" is a relative question. 10E-3 >> is typically considered quite elevated (not to say - unacceptably >> high) collision probability. Given that you can have hundreds of >> entries, this probability is even worst. Given that each collision >> requires re-hashing, which could provoke other collisions, we end up >> with a problem I consider to be quite dangerous. > > Appendix E cites different numbers than you do above. > For a server with 1000 hashed YANG names and a hash of 30 bits, the = probability of a single clash in a given server is 5*10^-4. > That means that in an installation with 2000 servers containing = disjunct sets of 1000 YANG names (total of 2 million YANG names), there = is on average one server with one clash. > There being more than one clash has a probability that is 10^-3 lower. > In my opinion these are acceptably low probabilities, because they = promise quite small rehash information in the clients (In this case: no = rehash or one server with one clash) > BTW Andy has hashed all YANG names in all to him known modules and no = clash occurred. As I am quite lazy, I like using tools. = http://davidjohnstone.net/pages/hash-collision-probability = With a hash value over 30 bits, with 20 servers with 1000 YANG names the = probability of a collision is 17%. Actually, I was using your numbers, = and I do not consider that this will be a major problem by itself. The = implications are that you WILL have hashes.=20 > >=20 >>> By the way, by relying on identifier assignment, there is also a = finite probability that the same identifier is allocated to names on = different modules (a hidden clash), due to power failures, undetected = transmission errors, or simply copying mistakes. >>> I recommend that in the security section of the identifier = assignment draft, it is discussed how modules are detected with an = identifier that has been assigned without going through the registration = process. >> That's a non-issue. > > I regret that you take this issue so lightly. > When there is no SDO that makes YANG name number allocation part of = the certification process, YANG module writers are not very motivated to = pass through a registry and assign the registered numbers. > Consequently, servers may use identical numbers for different YANG = objects. > This means that the extension of your installation with a server runs = the risk of duplicate identifiers. > You need a procedure to test this, or at least write text that this a = reasonable hazard. Too long to develop here, but the crux of the matter is that the way = YANG modules are used in constrained devices should influence the system = design. The main points are: 1) we need 100% RESTCONF / YANG compatibility 2) we don=E2=80=99t need 100% compression of all YANG modules (most = actually do not concern constrained networks) 3) people / SDOs / system integrators that want to run a given YANG = module in a constrained network are quite interested in having their = identifiers compressed The reason I claim this is a non-issue is because there are many ways in = which we can guarantee that identifiers are not assigned to different = SDOs / YANG modules / etc. etc.=20 > >>> Hope this will stimulate further discussion. >>> Peter >> Thanks for the useful remarks. I am glad when we have constructive >> discussion. Sorry, for the brevity. >> Best, >> Alexander To conclude, I think that we=E2=80=99ve initiated a very important = process of splitting the CoMI/CoOL proposals and converging on a common = ground (which is actually quite straightforward). Some details must be = clarified, of course, but in general I don=E2=80=99t see any major = issues. The only real issues/questions will actually be solved by simply = considering: 1) the constraints of constrained networks and devices (the REASON why = there is CoMI/CoOL) 2) the way people use YANG/RESTCONF Best, Alexander >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_0D054025-4596-4F6F-98EA-1CA327E64C60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Peter,

Once again, sorry for the brievity.

Important remarks to keep in = mind:
1) there is a seamless way in which you can = include hashes within a Structured ID (hashes are a subset of structured = IDs).
2) hashes are incompressible. Structured IDs = are very-well adapted to compression.

As we are working on converging on the = CoOL and CoMI approaches, it seems to me that 1) and 2) allow for a = graceful cooperation in this area.

See inline.

Le = 19 nov. 2015 =C3=A0 08:43, peter van der Stok <stokcons@xs4all.nl> = a =C3=A9crit :

Hi Alexander

see between <pvds> and = </pvds>

Alexander Pelov schreef op = 2015-11-18 15:23:
Hi Peter,
I'm quite busy these days. I = would like to send you a detailed
response, but = unfortunately this will be impossible today.
Please, see = in-line for some initial remarks.
Le 18/11/2015 09:09, = peter van der Stok a =C3=A9crit :
Hi Alexander,
I like to react to your = presentation of CoMI during the Friday CoRE meeting.  That is = necessary for me to understand the underlying factual discussion.
Your statement =E2=80=9CA hash clash 5 years down the road = can break your network=E2=80=9D needs some clarification. I interpret = that, out of the blue, a hash clash can occur and lead to problems in = the network. This is simply not true. A new hash clash may occur when = modules are changed and recompiled in a server. At that moment and = before the server is made operational hash clashes are detected and = remedial actions can be taken.
One of the = specific cases I cited is, when you have your network
running for months, maybe several years, before updating a = YANG
module, which leads to hash clash. This leads to = unexpected protocol
exchanges (e.g. clash-file loading), = unexpected memory allocations
(the clients must learn that = some of its servers have these new
clashes, while others = have some other clashes, and so forth), bugs
that have not = been tested for long time, ...

<pvds>
I do not share your concern. hashes are = generated before loading of the module, hash clashes are easily = verified, and rehashes are also done before loading of the = module.
The rehash protocol = concerns one client and one server and can be tested in = isolation.
Hash clashes are easily = simulated.
</pvds>

As = indicated, the problem is not that your resource-unconstrained, = human-operated compiler will not work flawlessly. It certainly = will! 

The problem is that you = have your hundreds of devices, coming from different manufacturers, = working in a given manner, until one day you update some of them, which = provokes all these unseen exchanges (rehashing), and CAN break your = network 5 years down the road. (the statement of my = presentation).

The biggest problem = is actually thing-to-thing communication. With hashes you have no = rendez-vous points within the hashed space.


Your next = statement =E2=80=9Chashes are underspecified=E2=80=9D also needs some = clarification. I understood from you that the remark was motivated by = the absence of a full-proof process defining the solution of hash = clashes. Such a process is not necessary to assure inter-operability. = Once solved, the server returns the unique rehashed values and there is = no need to specify how the rehash values are reached. Nevertheless, the = draft suggests that a tilde is prefixed to the YANG name, after which it = is rehashed. There is a very small probability that the new hash clashes = with another one. Actually, you said to be afraid that the hashing = algorithm may continuously generate the same set of clashing values = independent of the prefix. I have no idea if this is true, and do not = propose to check it for murmur.
I've though = on how to handle this specific question for a long time,
and= unfortunately you cannot guarantee that re-hashing will no
guarantee new hash clash. Which could, in turn, generate new = clashes.
Each clash leads to two new names that need to be = rehashed.
I agree = that for efficiency reasons the same rehash process should be followed = in all servers such that all servers with the same set of module = versions arrive at the same rehash values. An approach different from = rehashing is to assign the lowest not assigned natural number to the = clashing names in lexicographical order. That will generally mean that = two colliding names get the values 1 and 2 assigned, and very rarely the = values 3 and 4 may be used.
I think that = Structured IDs provide a way of handling this in a
reasonable manner. We've already discussed how in a = structured ID you
can have hashes.
<pvds>
I showed that the problem = above (continuous generation of hashes) can be easily avoided.

The problem = is not the generation of hash-free clash-files. I am more then persuaded = that you can do this. 

The = problem is that the collision probability increases.

</pvds>
Last I should like to make a remark about probabilities. The = whole world around us is based on probabilities. For example, there is a = finite probability that a fatal fault will occur in an airplane during = one hour of flight. Or that during digital transmission bits are toggled = without detection by the checksum. These probabilities are calculated = and should be smaller than a given probability value. This is a = well-established engineering practice. Therefore, the clash = probabilities are calculated in appendix E of the CoMI draft. It shows = that for the targeted hash size and number of names, the probability = that more than one clash occurs is 10^-3 smaller than the probability of = one clash. These are quite small values.
What = constitutes a "small probability" is a relative question. 10E-3
is typically considered quite elevated (not to say - = unacceptably
high) collision probability. Given that you = can have hundreds of
entries, this probability is even = worst. Given that each collision
requires re-hashing, = which could provoke other collisions, we end up
with a = problem I consider to be quite dangerous.
<pvds>
Appendix E cites different numbers than you do = above.
For a server with 1000 = hashed YANG names and a hash of 30 bits, the probability of a single = clash in a given server is 5*10^-4.
That means that in an installation with 2000 = servers containing disjunct sets of 1000 YANG names (total of 2 million = YANG names), there is on average one server with one clash.
There being more than one clash has a = probability that is 10^-3 lower.
In my opinion these are acceptably low = probabilities, because they promise quite small rehash information in = the clients (In this case: no rehash or one server with one = clash)
BTW Andy has hashed all = YANG names in all to him known modules and no clash occurred.

As I am = quite lazy, I like using tools. http://davidjohnstone.net/pages/hash-collision-probability<= /div>
With a hash value over 30 bits, with 20 servers with 1000 YANG = names the probability of a collision is 17%. Actually, I was using your = numbers, and I do not consider that this will be a major problem by = itself. The implications are that you WILL have hashes. 

</pvds>

By the way, by relying on identifier assignment, there is = also a finite probability that the same identifier is allocated to names = on different modules (a hidden clash), due to power failures, undetected = transmission errors, or simply copying mistakes.
I = recommend that in the security section of the identifier assignment = draft, it is discussed how modules are detected with an identifier that = has been assigned without going through the registration process.
That's a non-issue.
<pvds>
I regret that you take = this issue so lightly.
When there is no SDO that = makes YANG name number allocation part of the certification process, = YANG module writers are not very motivated to pass through a registry = and assign the registered numbers.
Consequently, servers may use identical numbers = for different YANG objects.
This means that the = extension of your installation with a server runs the risk of duplicate = identifiers.
You need a procedure to = test this, or at least write text that this a reasonable = hazard.

Too long to = develop here, but the crux of the matter is that the way YANG modules = are used in constrained devices should influence the system design. The = main points are:
1) we need 100% RESTCONF / YANG = compatibility
2) we don=E2=80=99t need 100% compression of all = YANG modules (most actually do not concern constrained = networks)
3) people / SDOs / system integrators that want to = run a given YANG module in a constrained network are quite interested in = having their identifiers compressed

The reason I claim this is a non-issue is because = there are many ways in which we can guarantee that identifiers are not = assigned to different SDOs / YANG modules / etc. etc. 

</pvds>
Hope this will stimulate further discussion.
Peter
Thanks for the useful = remarks. I am glad when we have constructive
discussion. = Sorry, for the brevity.
Best,
Alexander


To conclude, I think = that we=E2=80=99ve initiated a very important process of splitting the = CoMI/CoOL proposals and converging on a common ground (which is actually = quite straightforward). Some details must be clarified, of course, but = in general I don=E2=80=99t see any major issues.

The only real issues/questions will actually be = solved by simply considering:
1) the constraints of = constrained networks and devices (the REASON why there is = CoMI/CoOL)
2) the way people use YANG/RESTCONF

Best,
Alexander




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

= --Apple-Mail=_0D054025-4596-4F6F-98EA-1CA327E64C60-- From nobody Thu Nov 19 02:01:49 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0981B3121 for ; Thu, 19 Nov 2015 02:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dx0vlIfeNVn for ; Thu, 19 Nov 2015 02:00:06 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A311B3125 for ; Thu, 19 Nov 2015 02:00:05 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud3.xs4all.net with ESMTP id jN031r00D4d84Ai01N032d; Thu, 19 Nov 2015 11:00:03 +0100 Received: from [2001:983:a264:1:5cbf:6d13:c88d:6742] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Nov 2015 11:00:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 19 Nov 2015 11:00:03 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> X-Sender: stokcons@xs4all.nl (z+DecrVnU1T1CqbFVLylf6gT1tEAc20k) User-Agent: XS4ALL Webmail Archived-At: Cc: lhotka@nic.cz Subject: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 19 Nov 2015 10:00:08 -0000 Hi CoOL authors. I have looked at your section 5, and see an enormous overlap with the CoMI section 6. Actually the two proposals are almost completely interoperable, with a few exceptions. Much of the CoMI proposal is based on the work of Ladislav Lhotka, described in draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it extensively. In the CoOL draft the yang-json draft is ignored. That is a pity because you are redoing much of the work already done in the yang-json draft. In the CoMI draft we used the results of yang-json draft, exchanged the YANG name by the hash value, and passed it through the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant solution. Below, I have summarized my comparison between CoMI YANG to CBOR and CoOL YANG to CBOR. Please check for omissions and mistakes. Differences concern Binary byte string and Bits. The CoMI choice of CBOR type is derived from yang-json, and I should like to hear the opinion of Ladislav on this aspect. Other differences concern decimal64, and int; but I expect that is an oversight in the CoOL draft. A major difference is the encoding of lists and list instances; I discuss that in a separate e_mail. Given the overlap of work and the need for the expertise of the netmod WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and uses as much as possible the contents of yang-json draft. Alternatively, I can imagine that CBOR mapping is added to the yang-json draft if the author, Ladislav Lhotka, and the WGs agree with that. Greetings, Peter ______________________________________________________________________________ Comparison of draft veillette-core cool, denoted with CoOL With draft vanderstok-core-comi, denoted with CoMI And draft ietf-netmod-yang-json, denoted with yang-json Simple YANG type can be : Binary byte string: CoMI, major type 2; CoOL, major type 0 Bits: CoMI, array of text; CoOL, major type 0 Boolean: CoMI, major type 7 (20,21); CoOL, major type 7 (20,21) decimal64: CoMI, major type 0 (pos) and 1(neg); CoOL major type 0 empty: CoMI major type 7(22); CoOL major type 7(22) enumeration: CoMI, major type 0; CoOL major type 0 identityref: CoMI, major type 3; CoOL major type 3 int8, int16, int32, int64: CoMI, major type 0 (pos) and 1(neg); CoOL major type 0 leafref: CoMI, follows leaf type; CoOL follows leaf type string: CoMI, major type 3, CoOL major type 3 uint8, uint16, uint32, uint64: CoMI, major type 0; CoOL major type 0 In netmod-yang-json draft JSON objects are used: JSON object := { name: JSON object}, where name is a string. For CoMI and CoOL the name can be an integer which is valid for diagnostic JSON used for CBOR, giving: CBOR object := {integer: CBOR object} Leaf: Yang-json, Name : value, where name is the string identifier of the leaf, and value of Simple YANG type CoMI: major type 5 containing: uint64, value; CoOL: not defined Union: Yang-json, use corresponding media type for type of value CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type anyxml, YANG-json, value can be of any type. CoMI, not applicable; CoOL, can be any CBOR type Anydate, Yang-json, follows container CoMI, not applicable, CoOL, not applicable container, yang-json, name: JSON object CoMI: major type 5; CoOL, major type 5 leaf-list yang-json, name: [ value 1, value 2,鈥︹ CoMI, major type 4, CoOL, major type 4 List Yang-json, name:[ JSON object1, JSON object2, 鈥.] CoMI, major type 5 of major type 5, CoOL, major type 4 of major type 5 -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org From nobody Thu Nov 19 02:07:26 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1849F1B3139 for ; Thu, 19 Nov 2015 02:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeumoqM0tBSM for ; Thu, 19 Nov 2015 02:05:53 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4621B2B04 for ; Thu, 19 Nov 2015 02:05:52 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.214]) by smtp-cloud3.xs4all.net with ESMTP id jN5r1r00F4d84Ai01N5rXr; Thu, 19 Nov 2015 11:05:51 +0100 Received: from [2001:983:a264:1:5cbf:6d13:c88d:6742] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 19 Nov 2015 11:05:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 19 Nov 2015 11:05:51 +0100 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> X-Sender: stokcons@xs4all.nl (+pvqFLLFY7kaovOsj26bTG5EOFEWE8kw) User-Agent: XS4ALL Webmail Archived-At: Cc: lhotka@nic.cz Subject: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 19 Nov 2015 10:05:55 -0000 Hi CoOL authors, This e_mail complements my earlier e-mail on YANG to CBOR mapping, and explains the proposed list encoding. Both the draft yang-json and the CoOL draft encode a list as an array. In the yang-json case as a JSON array, and in the CoOL case as major type 4 of major type 5 objects. This encoding prevents the selection of list instances on the basis of the key values from the payload alone. In CoMI the list is encoded as a major type 5 of major type 5 objects. This deviation from the yang-json mapping is motivated by the wish to transport individual list instances and identify the instances in the payload from the key values. This is especially important in case of PATCH operation on list instances. Two cases are to be looked at: (1) the list definition specifies one or more key elements, and (2) the list definition does not specify a key element. We will start with a list containing key elements. It is the wish to transport only those list elements with a unique key value, either to support a PATCH or a FETCH command. Therefore it is required that the payload allows the selection and identification of these list element on the basis of their key values. Using the diagnostic JSON notation used for CBOR diagnostics, the payload containing a number of elements with key values should look like a JSON object with the structure list-name: {key: value}. Both key and value are composed of JSON objects separated by commas. For example consider the following YANG list specification: module foo { namespace http://example.com/book; prefix 鈥渇o鈥; revision 2015-06-07; list B { key 鈥渒ey1 key2鈥; leaf key1 {type string;} leaf key2 {type string;} leaf coll {type int32;} leaf counter {type int32;} } } Consider the transport of two instances specified by <鈥渒ey1鈥 = 鈥渂ook1鈥, 鈥渒ey2鈥 = 鈥渁uthor2鈥> and by <鈥渒ey1鈥 = 鈥渂ook5鈥, 鈥渒ey2鈥 = 鈥渁uthor3鈥> out of a larger set of instances. The representation is different from the yang-json one for the reasons explained above. The payload will look like: {"B" :{ {"key1" : "book1", "key2" : "author2"} : {"coll" : 500, "counter": 66} , {"key1" : "book5", "key2" : "author3"} : {"coll" : 444, "counter": 11} } } Which translated to CBOR yields: a1 # map(1) 61 # text(1) 42 # "B" a2 # map(2) a2 # map(2) 64 # text(4) 6b657931 # "key1" 65 # text(5) 626f6f6b31 # "book1" 64 # text(4) 6b657932 # "key2" 67 # text(7) 617574686f7232 # "author2" a2 # map(2) 64 # text(4) 636f6c6c # "coll" 19 01f4 # unsigned(500) 67 # text(7) 636f756e746572 # "counter" 18 42 # unsigned(66) a2 # map(2) 64 # text(4) 6b657931 # "key1" 65 # text(5) 626f6f6b35 # "book5" 64 # text(4) 6b657932 # "key2" 67 # text(7) 617574686f7233 # "author3" a2 # map(2) 64 # text(4) 636f6c6c # "coll" 19 01bc # unsigned(444) 67 # text(7) 636f756e746572 # "counter" 0b # unsigned(11) The corresponding yang-json draft encoding - that allows transport of a selection of instances- does not specify the key fields and would have looked like: {"B" : [ {"key1" : "book1", "key2" : "author2鈥, "coll" : 500, "counter": 66 } , {"key1" : "book5", "key2" : "author3", "coll" : 444, "counter": 11, } ] } Suppose there are no key elements specified. In that case it is impossible to specify the wanted list elements, and always the whole list must be transported. In the case of a list without key specification is is best to use major type 4 composed of major type 5 to transport the list, as is specified in yang-json draft. Consider the following YANG list Module foo{ Namespace http://example.com/book; Prefix 鈥渂o鈥 Revision 2015-06-7 List B { Leaf title {type string;} Leaf author {type string;} Leaf coll {type int32} Leaf counter {type int32} } } Suppose the list contains two elements. The transport payload of the two elements looks like: {"B" :[ {"title" : "book1", "author" : "author2", "coll" : 500, "counter": 66} , {"title" : "book5", "author" : "author3", 鈥渃oll" : 444, "counter": 11} ] } This payload is identical to the yang-json payload. Which yields the corresponding CBOR code. a1 # map(1) 61 # text(1) 42 # "B" 82 # array(2) a4 # map(4) 65 # text(5) 7469746c65 # "title" 65 # text(5) 626f6f6b31 # "book1" 66 # text(6) 617574686f72 # "author" 67 # text(7) 617574686f7232 # "author2" 64 # text(4) 636f6c6c # "coll" 19 01f4 # unsigned(500) 67 # text(7) 636f756e746572 # "counter" 18 42 # unsigned(66) a4 # map(4) 65 # text(5) 7469746c65 # "title" 65 # text(5) 626f6f6b35 # "book5" 66 # text(6) 617574686f72 # "author" 67 # text(7) 617574686f7233 # "author3" 64 # text(4) 636f6c6c # "coll" 19 01bc # unsigned(444) 67 # text(7) 636f756e746572 # "counter" 0b # unsigned(11) -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org From nobody Thu Nov 19 02:08:28 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8E1B314A for ; Thu, 19 Nov 2015 02:07:03 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvqwYOEGxOWg for ; Thu, 19 Nov 2015 02:06:59 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320A21B3147 for ; Thu, 19 Nov 2015 02:06:57 -0800 (PST) Received: from AM3PR06CA040.eurprd06.prod.outlook.com (10.141.192.158) by DB4PR06MB159.eurprd06.prod.outlook.com (10.242.155.145) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 10:06:38 +0000 Received: from AM1FFO11FD043.protection.gbl (2a01:111:f400:7e00::115) by AM3PR06CA040.outlook.office365.com (2a01:111:e400:882b::30) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 10:06:38 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD043.mail.protection.outlook.com (10.174.64.232) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Thu, 19 Nov 2015 10:06:38 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 11:06:37 +0100 From: Somaraju Abhinav To: Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbW5jNwRAHeU+Rg/6jmUcLNJ6gTL6AgAAcVgCAAOkigIAAHgWEgAB6WYCAATLOoQ== Date: Thu, 19 Nov 2015 10:06:37 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net>, In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72ATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD043; 1:szY1jtlaREqxx9kWLQJeEix+DXZSflw05V6AYDu3iUMtM22+RSmy5rVb3w1KN8e/3kg0Y2ckRYDHwvzXrApWxk6ccpZlnhbk2FPAG5ubD8iweLC3Xk3qT4JOLArvR/dywYjcFGarNh8Jm/bbmrhUESANBMhfffLZkuiMsS+BkCYC7oqUWQC8QMux6T8WpFeGtoTcYLnLjfzdRLQuxSxn0Ui+kMyfKEW/LudAvI6UmnZcNla6YE4CAZdxgayYEUxpBLnfrmvlBDyIPJAkbp06zmsIn8CQp0z1fR+58+pIeJw9kugdTncXxJMv//AYTU0qgXobYzcUR7i6jcgL+8xEwWx/KepCtbKjidAyLOOWRos= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(57704003)(24454002)(189002)(199003)(561944003)(33656002)(53416004)(87936001)(5890100001)(110136002)(104016004)(86362001)(69596002)(189998001)(5008740100001)(15975445007)(102836003)(106466001)(6116002)(55846006)(5004730100002)(3846002)(2900100001)(16236675004)(84326002)(81156007)(512934002)(2920100001)(11100500001)(54356999)(5003600100002)(6806005)(50986999)(106116001)(5001960100002)(93886004)(92566002)(5007970100001)(19580405001)(26826002)(76176999)(300700001)(2950100001)(5001920100001)(19580395003)(586003)(19617315012)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB159; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 2:7qNao2FZ6hS3/8l93EBOhQ3ngPj+HvSQbYLWsFBn/TC3LNrA9Bd7Muk3WTrkViOEhDDCqvTo4zBX0IG71ymA/ZW0fkj/JR5+ie8Mk77KldxD71uq5JQC2MrdYfW4c6fWK9xNeg+r1/NXVXO4sDc6+XmyzBvniCyPzLzzrW39Zko=; 3:oj4+tX9D/60Pxa8pwWtAZNUhiYUxLf/P97SOA4jeMTutcF5YaiDmhld5Qe4XYCzKy12MFxTLEWwMTPh3+KZL9IBNo47xJ4JL7Ca1N2JGVtT33VoXWTWN1MUGZIT7ttRwdpc7z0BERKP5PZocMEJ+3rFX3aiawBPHIhJDbEZtpgitFR0OKG93n/FOibLay0Em94bQ87f8VDQRygCsuWDbvbT1xvw5oo3ItWKXOCbBSJQ4myvUjD4bFFCMV7cO6f5PzP7UlJe2LP4yClWdxkr0RQ==; 25:2bkoGmjB29LaGX+gF/qwnbOVRMAfKgHqR6Lt168oJq5H3bkffa6O+MIevNykKoM0uB9qGEoMpqEW1/S2B/XEQDaIy+noGGjwtQGXzdEpUOqSOCbg85reoDJkg6bsoKXnxM863PaoqilHpbVshymWlXKD10q7uDrAKbtAP/KkkphTF1Qr5GbnWKPX/0+CSkf/ydjHTP8crFrXM+kC+KZtQ0k0jOEpIFBaekmY4TYl76trCjAI7G31UuG4xOoXIz7Zd+gnkrqtil5JZLdqrPiKFA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB159; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 20:4ERWQukkQFCeCTT5u80l/v1Y8D6/F9Vz7w50SKX4A70jKNpTKra+JCb5YUJmnPK7ZQjNP2dmjt2D4mHjYhX4QEKeiL/EA938E+zay4VUAqaEs9qZqGCsE+jWvRZHb9XPcYgar5HUkE8zReVs/nG5NO3txLPH+dJYuvGwVbXn6Mn1BdRVKMY/3xErGGYhpchFsGfzk3PbdbxuILnhHdVLVkejRpfrOINMei0sMVBhujZoEcHYnY7rICJPFJmi1raDKh8phIoDzs8QhY93Fd48Dsj9GbxV5+pU5eO1tzRNEss9klAfEC8LR0pZdtYUY3X5EIswwsfJt52LxXeEyEKJl+NuKzajK1D+xRwERuAyfGlw/4TLICOwBXl1nv6f3v/PjaRmkQsagY0WCJjGh2D272twisC4e/4wtAcj1ePN1QeSRpwGMUWYsnkFEQqCYrvAFaZo205othrJSMNtb1kDLMa8Efjp8fQbntYt/QwRy5SPI3/rbRCCZbcpO+vSwfNz; 4:KykNIm+5da83p4MTIT6ZCkaNKE6k22VVZys8DsUzg2kgLmpG9mtjwdISo53Vl6eNtAu+0Jdy5NIWqx/F1+bX4fb3VYu0E/yRDnpSwAstAhlwu1b8OE9JLbaxjbL+yKy5w7judrYoQKeBR7aCaKehDN6PrVHxIxntE8GkJOjHU9PyZ8Dke7WUWkpJyi7daOD8nYfIwWiCtsofHaN9+RUk+QVvUGMpi9w2aHWSRByb/2kJXT0hFYfWO3hSvN5yDbiQyuQfe4OLtbKZ7Fuz5mLokiXsq1zzGGdSkcp62KaGJxl2jvLLWnS7poTKawXQaE6v7uttazTfziS3P4kFf6Kh6Ywsq6UFsebewhbvpl9SW6vGORL3z5dGj3WuCJne3Fbb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(262738631018165)(216554174695431); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB4PR06MB159; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB159; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB4PR06MB159; 23:RuiXUC359fjxTFzqEQr93e/0gyW8Mr/16HcfBHzeUW?= =?us-ascii?Q?bV7PllLdJDNl0Hj/7TyNwYWPa7hppIH9tgG+FY7p4qdJwM9ysQIw1dIxaYvc?= =?us-ascii?Q?ZWM9rTZSdiUdoc+bGFPKEZ0n7m0B0+3oFZb/B0mR3485lau1NFtfPWi7Pg13?= =?us-ascii?Q?e5+LrupGaLixXJ5h7Wuq/kwJiCioJ94LgYWwKHJDkwbglw5TgQ/xJ3CA7RVB?= =?us-ascii?Q?bG4kE7PLUF+Y5WbF/A49q6VmwHACBZN6r6g4ovjhipCYJlAsOSKRodeVFdSW?= =?us-ascii?Q?mnNvfU49WJEaqVeu4y4b7Y0AIt/AT7OELV+YS83QjDv76W5e1cVqVdbEfyvf?= =?us-ascii?Q?BYPZ+Oxh0jtwavb9/JTtlXSYcCAhgQd5dBAdNQRKX2HcdKaMF6SdnZtY8zt9?= =?us-ascii?Q?+8babQbZPaZGF6aC/XjJHwZx/OVeET/qCwqPkKV7PA7G1ueuUb+9zZQSsSxM?= =?us-ascii?Q?UNP87iHQaxy39XV/qCQ0jc43TqHpXm2g/R5OigjwOK21mi6BP7vVS0jQ2GRq?= =?us-ascii?Q?7KfMUP+u8NZ+D6yYHVl+vu5jHpNNY5iouSlSdun3MASc2n+g6l5IscOQv+S8?= =?us-ascii?Q?xT5kAIP2PhUEhcWhEwuqRv8sXZJt7qLHfI5l3pj73ynOKcgkcmzZhojxg93s?= =?us-ascii?Q?gMo26bWfqbtLBCzFCFGHQXpZ31bcApUKqKYOp9QZpMYprKwg2TFh/0wz73kG?= =?us-ascii?Q?KQOl9b9eXwiPw2wrren+YXSQSqrKP+J/8Nly4g+LIrjleU+Ohd+HVkuAnEZy?= =?us-ascii?Q?MZuQoTO6qm1zoNFQft6XU/uTEFLrcSLQc+6mhu9IjYGe71hiqn+Oeh5XHIcx?= =?us-ascii?Q?j+9bonVkEg5QF8I7d+YNRhpkf0+p4bdEayhMrdZaA2TTOZlA3jYFS+bv+cWf?= =?us-ascii?Q?NcM3B4KaSypPXZLMllw6r6Q8lWYxRZhHRwQk121Fz4UobiLIgmCZOYzZH4f3?= =?us-ascii?Q?9ElClmDPPmLvdTsxVOkqFavfbeFYdLEHZtiH4eQeCpB1e3sX8MyGXkJJ/rRo?= =?us-ascii?Q?t9Xhy2mkL155Kc8nfAZIll9iR05h8W+v+NY/KMtCq9JvVSmzpO/jLG2Dx8gZ?= =?us-ascii?Q?4CpX0PmnFThgRSZzJiTMMVWuk6seUaLaj9uboI5O14wAZow6vEnRkZkeGHhX?= =?us-ascii?Q?HUKf5X0G0Q/akXp2GTCk9uvni6Cw+Z+ywV3X4gD7MYNtXQIwq+EeInmUM1uK?= =?us-ascii?Q?sV07FG4rakBTx0oemO3WAH9krDNHo2khmKxg40h+Ss2kX442n0o4nToHzt83?= =?us-ascii?Q?lQ9vRsp79t2l2SneAmynXgk1aF7NJdHHfJ1qrT26tElPsqZjSqNNiCxZKIZL?= =?us-ascii?Q?jKaobXyS6MOYHNHKeRaXbVb95WEopUwFfHDnESR44PA7uFBwuegM7OqBPRA1?= =?us-ascii?Q?quw0Z4N3Bz7oB8RkdT8QOH1WY=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 5:OL625yIkKmPthyKxD713LvKieKFVjXfzq/J5vTqyFri7kY4Tx6uSZsDY67Ihv1gzHdmj4u4prbTQgGoFLdElZxCUg46i6fNrqDIXTSeKQN91QntGzwBFGKxllYb9/L9Mm+MufyhzlwDiYKsbWl526w==; 24:qvwLILKCh27Xroif+/O5uSeRQNVqQQcPYv6AzsuzoB2asxCHc46OEc5RqNdg63994w7rAEk3etb8OWZdbvZJAOThD0+qTwBFdpC+CEE2OaU=; 20:p53D2vVzLc2tht7uo8T4inj3KDlisrjl1nI+cpGd4+Zj3GxJrfD6MWeyis+EfLMhM/XnZGtwEJk0ZfZsBGXFOw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 10:06:38.3608 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB159 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 10:07:03 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72ATBRAGMSX02itis_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andy, please see inline for comments. ________________________________ From: Andy Bierman [andy@yumaworks.com] Sent: Wednesday, November 18, 2015 5:32 PM To: Somaraju Abhinav Cc: consultancy@vanderstok.org; Core Subject: Re: [core] CoMI Cool draft splits On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav > wrote: Hi Peter, I like your proposal of starting with the four drafts. Just a few comments - Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my = opinion, in constrained networks we will not support two management protoco= ls one for networking and one for application layer. Therefore, we should s= upport both in the function set. We don't know this term "YANG application layer module management" in the N= ETMOD WG. The semantics of the YANG module can be anything. The same language is use= d for devices and controllers, as well as application and server code generation by many = tools. [AS] Agreed. But we understanding this explains what function set we want t= o support. One example was the argument to include RPC/operations. I think = CoMI currently does not support RPCs because the need to do so was not clea= r from a network management point of view. However, for applications, I can= provide clear reasons to do so. Same thing for "actions" from the Yang 1.1= draft. - Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But from= the perspective of being able to use a device management protocol, unless = we also get interoperability for access control/security mechanisms, the dr= afts will not be usable in the field. Would this be a replacement for NACM, which is how authorization is handled for YANG data. [AS] Yes. I think CoMI/CoOL should recommend something similar to NACM. Whe= ther it is based on NACM or something new that is coming from ACE/COSE is u= p for discussion. This also relates to the previous point about use cases. = Will we also use the same access control methods also for application layer= CoAP resources? - Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numberi= ng scheme as far as possible. So, my questions is the following: do we need= data node IDs consistent across versions of YANG modules. YANG is just like SMIv2 wrt/ permanent identifiers. [AS] I did not realise that all YANG modules MUST have permanent module ide= ntifiers. Could you please point me to the right reference where I can read= about this? Anyways, the permanent identifiers need not be the same as the= identifiers that should be used withing the API to access the modules them= selves (i.e the identifiers used withing CoOL to access data). Therefore, m= y questions still stays the same, do data node IDs need to be the same acro= ss multiple versions of the same module. Once an ID is assigned it is never removed. The 'status' statement is used to manage lifecycle issues like obsolete obj= ects. So you can assume revision N+1 is a superset of N (at least for the purpose of object identification). When a module is updated in the server, we usually attempt to minimize the = change such that existing client code will continue to work without an upgrade. This is how YANG Hash works. If the Cool numbers are version-specific, the= n a client needs to store multiple sets of IDs to work with each version, and= also needs to be updated anytime a server it manages is updated. Abhinav Andy ________________________________________ From: core [core-bounces@ietf.org] on behalf = of peter van der Stok [stokcons@xs4all.nl] Sent: Wednesday, November 18, 2015 8:27 AM To: Andy Bierman Cc: Core Subject: Re: [core] CoMI Cool draft splits > > I think the YANG Hash draft should be separate from the protocol. > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. > I agree with Andy here. Although I sympathize with Rodney, that once the four drafts are reality, the WG should decide about adoption and a recombination of documents. Peter _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________________________________ 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. ________________________________________________________ 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. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72ATBRAGMSX02itis_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Andy,
please see inline for comments.
From: Andy Bierman [andy@yumaworks.com] Sent: Wednesday, November 18, 2015 5:32 PM
To: Somaraju Abhinav
Cc: consultancy@vanderstok.org; Core
Subject: Re: [core] CoMI Cool draft splits



On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhin= av <abhi= nav.somaraju@tridonic.com> wrote:
Hi Peter,
I like your proposal of starting with the four drafts. Just a few comments<= br>
- Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my opinion, in constrained network= s we will not support two management protocols one for networking and one f= or application layer. Therefore, we should support both in the function set= .


We don't know this term "YANG application layer module management= " in the NETMOD WG.
The semantics of the YANG module can be anything.  The same langu= age is used for devices
and controllers, as well as application and server code generation by = many tools.
[AS] Agreed. But we understanding this explains what function set we w= ant to support. One example was the argument to include RPC/operations. I t= hink CoMI currently does not support RPCs because the need to do so was not= clear from a network management point of view. However, for applications, I can provide clear reasons to d= o so. Same thing for "actions" from the Yang 1.1 draft.
 
- Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But from= the perspective of being able to use a device management protocol, unless we also get interoperability for = access control/security mechanisms, the drafts will not be usable in the fi= eld.


Would this be a replacement for NACM, which is how authorization is ha= ndled
for YANG data.
[AS] Yes. I think CoMI/CoOL should recommend something similar to NACM= . Whether it is based on NACM or something new that is coming from ACE/COSE= is up for discussion. This also relates to the previous point about use ca= ses. Will we also use the same access control methods also for application layer CoAP resources?


- Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numbering scheme as far as possible. So, my qu= estions is the following: do we need data node IDs consistent across versio= ns of YANG modules.



YANG is just like SMIv2 wrt/ permanent identifiers.
[AS] I did not realise that all YANG modules MUST have permanent modul= e identifiers. Could you please point me to the right reference where I can= read about this? Anyways, the permanent identifiers need not be the same a= s the identifiers that should be used withing the API to access the modules themselves (i.e the identifiers= used withing CoOL to access data). Therefore, my questions still stays the= same, do data node IDs need to be the same across multiple versions of the= same module.

Once an ID is assigned it is never removed.
The 'status' statement is used to manage lifecycle issues like obsolet= e objects.
So you can assume revision N+1 is a superset of N (at least for th= e purpose
of object identification).

When a module is updated in the server, we usually attempt to minimize= the change
such that existing client code will continue to work without an upgrad= e.
This is how YANG Hash works.  If the Cool numbers are version-spe= cific, then
a client needs to store multiple sets of IDs to work with each version= , and also
needs to be updated anytime a server it manages is updated.


Abhinav

Andy
 

________________________________________
From: core [core= -bounces@ietf.org] on behalf of peter van der Stok [stokcons@xs4all.nl]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

>
> I think the YANG Hash draft should be separate from the protocol.
> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >

I agree with Andy here.
Although I sympathize with Rodney, that once the four drafts are
reality, the WG should decide about adoption and a recombination of
documents.

Peter

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments.

________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der nor the sender's company accept any responsibility for viruses and it i= s your responsibility to scan or otherwise check this e-mail and any attachments. --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72ATBRAGMSX02itis_-- From nobody Thu Nov 19 02:13:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC71B3162 for ; Thu, 19 Nov 2015 02:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY7NckmScf7s for ; Thu, 19 Nov 2015 02:11:53 -0800 (PST) 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 7D0EF1B3161 for ; Thu, 19 Nov 2015 02:11:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 50DD61483; Thu, 19 Nov 2015 11:11:52 +0100 (CET) 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 2jcGBFegN14E; Thu, 19 Nov 2015 11:11:50 +0100 (CET) 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, 19 Nov 2015 11:11:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 621E720054; Thu, 19 Nov 2015 11:11:50 +0100 (CET) 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 a1uARITIjZuL; Thu, 19 Nov 2015 11:11:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F99A2003B; Thu, 19 Nov 2015 11:11:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 367B338E315F; Thu, 19 Nov 2015 11:11:46 +0100 (CET) Date: Thu, 19 Nov 2015 11:11:45 +0100 From: Juergen Schoenwaelder To: consultancy@vanderstok.org Message-ID: <20151119101143.GA2107@elstar.local> Mail-Followup-To: consultancy@vanderstok.org, Core , lhotka@nic.cz References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> 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: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: lhotka@nic.cz, Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2015 10:11:55 -0000 I am not CoOL but as contributor I think that the CBOR encoding of YANG data should follow in style the JSON encoding document but it should not normatively depend on the JSON encoding document. The reason is modularity. There are systems that only want JSON and there are systems that only want CBOR. >From the NETMOD perspective, I am pretty sure CBOR is _not_ added to the JSON encoding document. The reasons is modularity (see above) and also the fact that the JSON document is pretty much done and several other documents depend on it and we won't hold things off for another N months. Whether the CBOR encoding is done in CORE or NETMOD can be discussed. I guess this is a decision whether this requires more CBOR expertise or more YANG expertise. Given that this work started being discussed in CORE, I personally would not mind to leave the work in CORE and to ensure that NETMOD is kept updated when things become stable (e.g., the CBOR encoding document goes to WG last call). /js On Thu, Nov 19, 2015 at 11:00:03AM +0100, peter van der Stok wrote: > Hi CoOL authors. > > I have looked at your section 5, and see an enormous overlap with the > CoMI section 6. Actually the two proposals are almost completely > interoperable, with a few exceptions. Much of the CoMI proposal is based > on the work of Ladislav Lhotka, described in > draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it > extensively. In the CoOL draft the yang-json draft is ignored. That is a > pity because you are redoing much of the work already done in the > yang-json draft. In the CoMI draft we used the results of yang-json > draft, exchanged the YANG name by the hash value, and passed it through > the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant > solution. > Below, I have summarized my comparison between CoMI YANG to CBOR and > CoOL YANG to CBOR. Please check for omissions and mistakes. > Differences concern Binary byte string and Bits. The CoMI choice of CBOR > type is derived from yang-json, and I should like to hear the opinion of > Ladislav on this aspect. > Other differences concern decimal64, and int; but I expect that is an > oversight in the CoOL draft. > A major difference is the encoding of lists and list instances; I > discuss that in a separate e_mail. > Given the overlap of work and the need for the expertise of the netmod > WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and > uses as much as possible the contents of yang-json draft. Alternatively, > I can imagine that CBOR mapping is added to the yang-json draft if the > author, Ladislav Lhotka, and the WGs agree with that. > > Greetings, > > Peter > ______________________________________________________________________________ > Comparison of draft veillette-core cool, denoted with CoOL > With draft vanderstok-core-comi, denoted with CoMI > And draft ietf-netmod-yang-json, denoted with yang-json > Simple YANG type can be : > Binary byte string: CoMI, major type 2; > CoOL, major type 0 > Bits: CoMI, array of text; > CoOL, major type 0 > Boolean: CoMI, major type 7 (20,21); > CoOL, major type 7 (20,21) > decimal64: CoMI, major type 0 (pos) and > 1(neg); CoOL major type 0 > empty: CoMI major type 7(22); > CoOL major type 7(22) > enumeration: CoMI, major type 0; > CoOL major type 0 > identityref: CoMI, major type 3; > CoOL major type 3 > int8, int16, int32, int64: CoMI, major type 0 (pos) and > 1(neg); CoOL major type 0 > leafref: CoMI, follows leaf type; > CoOL follows leaf type > string: CoMI, major type 3, > CoOL major type 3 > uint8, uint16, uint32, uint64: CoMI, major type 0; > CoOL major type 0 > > In netmod-yang-json draft JSON objects are used: > JSON object := { name: JSON object}, where name is a string. For CoMI > and CoOL the name can be an integer which is valid for diagnostic JSON > used for CBOR, giving: > CBOR object := {integer: CBOR object} > > Leaf: > Yang-json, Name : value, where name is the string identifier of the > leaf, and value of Simple YANG type > CoMI: major type 5 containing: uint64, value; CoOL: not defined > > Union: > Yang-json, use corresponding media type for type of value > CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type > > anyxml, > YANG-json, value can be of any type. > CoMI, not applicable; CoOL, can be any CBOR type > > Anydate, > Yang-json, follows container > CoMI, not applicable, CoOL, not applicable > > container, > yang-json, name: JSON object > CoMI: major type 5; CoOL, major type 5 > > leaf-list > yang-json, name: [ value 1, value 2,鈥︹ > CoMI, major type 4, CoOL, major type 4 > > List > Yang-json, name:[ JSON object1, JSON object2, 鈥.] > CoMI, major type 5 of major type 5, CoOL, major type 4 of > major type 5 > > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > -- 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 Nov 19 02:38:56 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89BB1B31AC for ; Thu, 19 Nov 2015 02:37:43 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1h-Nl2YWQG4 for ; Thu, 19 Nov 2015 02:37:37 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224971B31A1 for ; Thu, 19 Nov 2015 02:37:36 -0800 (PST) Received: from HE1PR06CA0039.eurprd06.prod.outlook.com (10.162.181.177) by DB4PR06MB159.eurprd06.prod.outlook.com (10.242.155.145) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 10:37:18 +0000 Received: from AM1FFO11FD002.protection.gbl (2a01:111:f400:7e00::114) by HE1PR06CA0039.outlook.office365.com (2a01:111:e400:51fa::49) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 10:37:17 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD002.mail.protection.outlook.com (10.174.64.84) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Thu, 19 Nov 2015 10:37:16 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 11:37:15 +0100 From: Somaraju Abhinav To: Juergen Schoenwaelder , "consultancy@vanderstok.org" Thread-Topic: [core] YANG to CBOR mapping Thread-Index: AQHRIrFTXNOJF8VKB0ykgcqez4yUdJ6jDz2AgAAXLvU= Date: Thu, 19 Nov 2015 10:37:15 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACEDF@ATBRAGMSX02.itiso.net> References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl>, <20151119101143.GA2107@elstar.local> In-Reply-To: <20151119101143.GA2107@elstar.local> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.8.124] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD002; 1:LXwAJDku2rFCTlFbJlyzkjKmPv3STGgRYJJF+yxyTBao4jAIxTUJ/2lYmuMN0eZIlaD17/TBg39pI9BRvwUGuLmCQL1p4ChRtn5y20sGNDRMwwVCOX0DY+XYqS5gCIqtIn3BS/Usloj+SYWX+YWN0RA5PbW9YszwnRLSSO4LWe+Asv8xUnj1N6iJxtLTmF4hUiWB9WpiGBM0vT0bnjtiWdF9s2vAsZNyHZmjAKGonEDGuFQp379Z3Yu0z6v2TZ9fe/onFg2yCBAKhHGkrjaKAX0iXzb3QvU0OdE8cyiSNYgRDDuRlaHZ8MICoSN+gRJAvAq/rNykONQQyu9gd8w+0r+o5YLGQFssvb8ADjWwvQI= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(24454002)(189002)(199003)(51444003)(561944003)(33656002)(53416004)(87936001)(5890100001)(104016004)(189998001)(86362001)(69596002)(5008740100001)(6116002)(15975445007)(102836003)(2501003)(23746002)(55846006)(106466001)(5004730100002)(3846002)(2900100001)(81156007)(2920100001)(54356999)(5003600100002)(6806005)(26826002)(47776003)(5001770100001)(50466002)(50986999)(106116001)(5001960100002)(92566002)(5007970100001)(19580405001)(76176999)(2950100001)(5001920100001)(19580395003)(586003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB159; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 2:+/DTlCLvZ47Son4u9q/sStCvVOLyS0dzl7kq9tjZKaC4ptvRDdbkNX4t+i3HXACcdwFauZn+jH63PeYMq7xJ/IP/6rPc9Tj6crzyGTQKQdvJQPH+H3PENXXgvCJMvy4pnGp4PTDoBEwJl1qcj0jk/q9F52zrooCqfJpZJ6qydLo=; 3:ixJEAlBc75y1fRVRBmOsMzu6fq9W4qCjPFk1qQV196R/11kU4cn8k9q2xnWJfDiPCySgP/PdnXQ0FdpiuTg3EJU0WRt2xT4DI1e/9dBXlWKhmnlKtfqovTFVUeVCrpOcinjkw8PsIcTxROWUlh5NIKN+pKqqfKrSOnfv2Z5bXzlaDpciEj4Xo/PA4pWVAMlEUgYyUsD4HUdcIeDes7JPde+9rzWyEizrHgWnGUvrNl8JfVIzjB+CIht4nulm4lRF1T/qVbSLe86I5YzLDIeL+Q==; 25:MtcViKZuhmPpXvbW4FvEQgjcNNXw4hJwxjrOis2jvSVYiZ/u0Y31q9e0ZvJqYreMskPWud0nUvR+oGft0nD1sI7TVY6WapKdduLfJej3VT36YgcB0fHnRy/cgsJ9XgA7Myt6GGv9yjkc+fnofSVpBQQs4Dr8nxrv7TbPHFryLYdA5Lb08vnyL663JA5dbwYAhoNqMYHCCtIayRUWW6KH9LLS7ZvA0pDvBM939PF+cQr1urQk1ZKihc/OnmDhZmz4mJsIJ8GGMs9eagtwZL1Y3A== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:DB4PR06MB159; X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 20:OIYBTu3nZSXmI4UCdPFlV4xi7o6RhOG/YjRKxybpPtDauP2+XtJ/oWqW8wp4bN59Cqv9IbHLxVC6x//fhR+eqQ0jb07bhcz4ve33T3CHaV6Oj9uSsrwqQUb+uTEZmzCiCwlQ6XrxVdMzEI8m9S/DnqrIsRasyVVFMs73M1Xd8mj1r/IA+BGPoiYwPuIziTf+WdaTN67nz5lYnP3lto3oX4CPrjY/w5d3Uo0k5EwC2RV9TcIR8BUU6vR7SMJbJvIJ7tXu84avRSZamddLEIuXNJQWTDbDnxq2CddybyKKnrK3apFbwYyTTLPeLtsjuWN6dHvhR8LQLbqPM0YctuzG0Mn1Pc1oQZWvPfPvqDyBlVdcYmA+YA5sPtvKSNA9CDCusfqFBdiU4AdFSYHBZF6Qz04himH1jdpmi53iCZghtnhXOml5tEA1h9a3diWUehxJWwaq/fsOlEULhkC63x8dv2ClxRo0Eu8c3e2XglUrezlSi8weS4jE3pS/zF3Cj2YT; 4:nvofuHIel6WTIleZIpZ+wF+jesjS2pwfrmBt0LulUKt/jtR6CoAfegVqhOSU/8AXnLAVtIKWVJ0cG9N1VIoqdpcxAM7HVBMguGBO8zi0F6Jg22yl3Nk1Sk4ioB6bAgcB7bRC1h9+CwwxxuPGjnc7oYPDeFDFBRkcCVY9wo6xVyeHObE4C80F0BblE4naPVXPWv9FJ5jjuldmXAHsOIP5lJ6Fh9m1IqkNF4J7XaTTjMKUmMDe8f9R8qHOv5iMnb2OYN6GEGXWNJMTHsd90xeLjXcws50M/4QK31S8Ap5PapefQwbE8HjzbnZ9OAdASp4Xg8ApGUkoSkrcz+4YGjnxcue5MYQ4642aNNY/Tjbe0UUPyVOCoE2n6bLzMB+e1/+0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB4PR06MB159; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB159; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB4PR06MB159; 23:K7EKELEmRPPMd0Lt6z1MxKadFy2zeAbOM2Yd9j?= =?Windows-1252?Q?Bmx3T4BWOP4eYXA6ALtuTTkshyctYOwpSrwTQDdCAJs500k5uJ8B4SaK?= =?Windows-1252?Q?Hi6GlSGIZDDCtmICTBhUbNyWkzLoCUAUQ4KpQzBpvholVnEsJvZEs/y5?= =?Windows-1252?Q?gffxvd/OldPS4ZgcEWUgFP1tMA1PvZuTbdPfGjNWkrR4dNkv0P5V9BtE?= =?Windows-1252?Q?CR3lTrtiZkLhqRnHsXyGKAY0LzCpXa5tMC9gDKQHxHtr7vzR3Gp7NRM5?= =?Windows-1252?Q?Jrs6JkB4mCP2TXFzYURQbtmLXYZU6qoOCLB2GeRwlVQlf9AXaAD2s+f5?= =?Windows-1252?Q?031SbyaUcf4pkK83FZyYCbT2ensgOvrPr3DKc/s0Bd1qQksfLdsTQFiA?= =?Windows-1252?Q?TzDMkw9GT3rCRtEOCCA5oaw88ZtgCn3CDOCyx1eqoLS3iyBYi8CaW69S?= =?Windows-1252?Q?cP5XzBEa8tcgrI1mfSYhzcFPZRAI4U1qF4CWKOUEeZu6kvpGd+nbX9Fd?= =?Windows-1252?Q?8F4HJJkDpgcq3ogVi756XB4qmTjHb3KIKoGGCR4mQ0Jyo/wgtF5167vp?= =?Windows-1252?Q?E7FTQMpDEQS9RIfsJEq4u8QOrP71j9nKut0LtX7WuckrgVTNRJPDoR8n?= =?Windows-1252?Q?NrFlwbQ01cRGILzhy8hKsGqQeznKbSgVx0Js0nrPPF9T5FlVwnXLjDUI?= =?Windows-1252?Q?uOpp06Bt/dQ7/QgksleZ7XZicTMrlqCyBeIdr/84/PbdDhHHute4gYVI?= =?Windows-1252?Q?Aj8EzUwJiLqZy4KtsBR4KpfYGB1r9W/yXJZAp9kJEHN3AytrPplh5k1l?= =?Windows-1252?Q?xEgPYyGe36PJ0c7WLWWACnfe09GH3q830wAxQWZrF7kI65QW0A2PsoMS?= =?Windows-1252?Q?TQK8z6SWCwFAntKWMPw6GGl9ozsow/35J+jYYZAj3/JDGwM7eWVJk571?= =?Windows-1252?Q?P3bvH/u6GZlGSUSGrvnU4QMEeBM3zLUbFXdo3NtR/kxEkWh5O9hc4yYx?= =?Windows-1252?Q?wHAGAEW9WjSmjAcW5mLBoic6cT6KxQiz6U0W8As3TDbCpQEHsdpKpS/A?= =?Windows-1252?Q?n51dvaEMO0e08u7cySPKPEVg2z4GqyGwNDbqcLyvXGvKItmqR+LLkT/2?= =?Windows-1252?Q?dWcwFF78tG/kWm8xwzTbWhXfpZpnp0l65KscR1IAJbkahZiWWyTGVFB0?= =?Windows-1252?Q?Mf2f0WMZNA7xmDc+pNbxpx5KnjoFCNPLb+wiWtGrPBavWWLa5bNG//te?= =?Windows-1252?Q?QA89fyW7fJrGwRPJck1F6hzJpJHAHVKJrm/h2NQRL0nDY5f5gixKl2Bc?= =?Windows-1252?Q?iLgEcUR1xsJ4kY0/rloekwMrPapX/kbthKLxYmuf6V7Am6hScKelSqqi?= =?Windows-1252?Q?6m60fEiyf8qbCq+1NmD4BCOMxzkwf3W8lxblD0oGeEUdFJZtog2WQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB159; 5:wSCHT+AgTX0tfWZNFei+pMn/Z9f1cCqMyobOt9T11R8cIwsEmfWTu4YP+uYojFMogqm8+QtveKQLFfjbe8i3VdbBxEc/u/xbTNvv77s0Zo04ecE0NDOYjwjb/lS+aRzfESDfhK9SxQyg1h65i1ZQsA==; 24:RhZd0bcuzQhQS1lamqBOw43K+C+olYExfH13cGuHSTTTERfeIoxVleOivQ8bRCfi3w6OcVFpXg7RphYsmCI1RiOhyTv1nUZJwFhDkpVkfrw=; 20:n9dz4w25pK3ME5xS4mgsdx+DuKH5KhTxXqD0z2LJL5v4d/zbDH+stIw5ss7eZUtmFtNKq6RWR6lbkPsmqfcKsw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: tridonic.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 10:37:16.7228 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB159 Archived-At: Cc: "lhotka@nic.cz" , Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 10:37:44 -0000 Hi Juergen, I agree with you about the modularity and like your proposal. However, ther= e is one issue we need to watch out for. The CBOR spec. [RFC7049] already s= ays something about converting from JSON to CBOR. So, we should probably be= careful that we do not have two ways of getting to CBOR from YANG - via YA= NG to JSON to CBOR vs YANG to CBOR. Abhinav ________________________________________ From: core [core-bounces@ietf.org] on behalf of Juergen Schoenwaelder [j.sc= hoenwaelder@jacobs-university.de] Sent: Thursday, November 19, 2015 11:11 AM To: consultancy@vanderstok.org Cc: lhotka@nic.cz; Core Subject: Re: [core] YANG to CBOR mapping I am not CoOL but as contributor I think that the CBOR encoding of YANG data should follow in style the JSON encoding document but it should not normatively depend on the JSON encoding document. The reason is modularity. There are systems that only want JSON and there are systems that only want CBOR. >From the NETMOD perspective, I am pretty sure CBOR is _not_ added to the JSON encoding document. The reasons is modularity (see above) and also the fact that the JSON document is pretty much done and several other documents depend on it and we won't hold things off for another N months. Whether the CBOR encoding is done in CORE or NETMOD can be discussed. I guess this is a decision whether this requires more CBOR expertise or more YANG expertise. Given that this work started being discussed in CORE, I personally would not mind to leave the work in CORE and to ensure that NETMOD is kept updated when things become stable (e.g., the CBOR encoding document goes to WG last call). /js On Thu, Nov 19, 2015 at 11:00:03AM +0100, peter van der Stok wrote: > Hi CoOL authors. > > I have looked at your section 5, and see an enormous overlap with the > CoMI section 6. Actually the two proposals are almost completely > interoperable, with a few exceptions. Much of the CoMI proposal is based > on the work of Ladislav Lhotka, described in > draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it > extensively. In the CoOL draft the yang-json draft is ignored. That is a > pity because you are redoing much of the work already done in the > yang-json draft. In the CoMI draft we used the results of yang-json > draft, exchanged the YANG name by the hash value, and passed it through > the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant > solution. > Below, I have summarized my comparison between CoMI YANG to CBOR and > CoOL YANG to CBOR. Please check for omissions and mistakes. > Differences concern Binary byte string and Bits. The CoMI choice of CBOR > type is derived from yang-json, and I should like to hear the opinion of > Ladislav on this aspect. > Other differences concern decimal64, and int; but I expect that is an > oversight in the CoOL draft. > A major difference is the encoding of lists and list instances; I > discuss that in a separate e_mail. > Given the overlap of work and the need for the expertise of the netmod > WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and > uses as much as possible the contents of yang-json draft. Alternatively, > I can imagine that CBOR mapping is added to the yang-json draft if the > author, Ladislav Lhotka, and the WGs agree with that. > > Greetings, > > Peter > _________________________________________________________________________= _____ > Comparison of draft veillette-core cool, denoted with CoOL > With draft vanderstok-core-comi, denoted with CoMI > And draft ietf-netmod-yang-json, denoted with yang-json > Simple YANG type can be : > Binary byte string: CoMI, major type 2; > CoOL, major type 0 > Bits: CoMI, array of text; > CoOL, major type 0 > Boolean: CoMI, major type 7 (20,21); > CoOL, major type 7 (20,21) > decimal64: CoMI, major type 0 (pos) and > 1(neg); CoOL major type 0 > empty: CoMI major type 7(22); > CoOL major type 7(22) > enumeration: CoMI, major type 0; > CoOL major type 0 > identityref: CoMI, major type 3; > CoOL major type 3 > int8, int16, int32, int64: CoMI, major type 0 (pos) and > 1(neg); CoOL major type 0 > leafref: CoMI, follows leaf type; > CoOL follows leaf type > string: CoMI, major type 3, > CoOL major type 3 > uint8, uint16, uint32, uint64: CoMI, major type 0; > CoOL major type 0 > > In netmod-yang-json draft JSON objects are used: > JSON object :=3D { name: JSON object}, where name is a string. For CoMI > and CoOL the name can be an integer which is valid for diagnostic JSON > used for CBOR, giving: > CBOR object :=3D {integer: CBOR object} > > Leaf: > Yang-json, Name : value, where name is the string identifier of the > leaf, and value of Simple YANG type > CoMI: major type 5 containing: uint64, value; CoOL: not defined > > Union: > Yang-json, use corresponding media type for type of value > CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type > > anyxml, > YANG-json, value can be of any type. > CoMI, not applicable; CoOL, can be any CBOR type > > Anydate, > Yang-json, follows container > CoMI, not applicable, CoOL, not applicable > > container, > yang-json, name: JSON object > CoMI: major type 5; CoOL, major type 5 > > leaf-list > yang-json, name: [ value 1, value 2,=85=85] > CoMI, major type 4, CoOL, major type 4 > > List > Yang-json, name:[ JSON object1, JSON object2, =85.] > CoMI, major type 5 of major type 5, CoOL, major type 4 of > major type 5 > > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > -- 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 ________________________________________________________ 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 Thu Nov 19 04:30:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE251ACE6E for ; Thu, 19 Nov 2015 04:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ1KjjvugrTR for ; Thu, 19 Nov 2015 04:30:38 -0800 (PST) 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 1176A1ACE67 for ; Thu, 19 Nov 2015 04:30:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB834162C; Thu, 19 Nov 2015 13:30:34 +0100 (CET) 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 ZzVN8QoDlvPN; Thu, 19 Nov 2015 13:30:32 +0100 (CET) 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, 19 Nov 2015 13:30:32 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 735312003B; Thu, 19 Nov 2015 13:30:32 +0100 (CET) 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 Xr82wRi7BluO; Thu, 19 Nov 2015 13:30:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92CCE2004E; Thu, 19 Nov 2015 13:30:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D55CB38E342F; Thu, 19 Nov 2015 13:30:25 +0100 (CET) Date: Thu, 19 Nov 2015 13:30:24 +0100 From: Juergen Schoenwaelder To: Somaraju Abhinav Message-ID: <20151119123024.GA3162@elstar.local> Mail-Followup-To: Somaraju Abhinav , "consultancy@vanderstok.org" , "lhotka@nic.cz" , Core References: <20151119101143.GA2107@elstar.local> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACEDF@ATBRAGMSX02.itiso.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: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACEDF@ATBRAGMSX02.itiso.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Core , "lhotka@nic.cz" Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2015 12:30:42 -0000 Yes, good point. I did not track this. We need to check this carefully and perhaps there is not even much left to do. But more likely we will detect differences and then we need to figure out what to do about them. /js On Thu, Nov 19, 2015 at 10:37:15AM +0000, Somaraju Abhinav wrote: > Hi Juergen, > > I agree with you about the modularity and like your proposal. However, there is one issue we need to watch out for. The CBOR spec. [RFC7049] already says something about converting from JSON to CBOR. So, we should probably be careful that we do not have two ways of getting to CBOR from YANG - via YANG to JSON to CBOR vs YANG to CBOR. > > Abhinav > ________________________________________ > From: core [core-bounces@ietf.org] on behalf of Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de] > Sent: Thursday, November 19, 2015 11:11 AM > To: consultancy@vanderstok.org > Cc: lhotka@nic.cz; Core > Subject: Re: [core] YANG to CBOR mapping > > I am not CoOL but as contributor I think that the CBOR encoding of > YANG data should follow in style the JSON encoding document but it > should not normatively depend on the JSON encoding document. The > reason is modularity. There are systems that only want JSON and there > are systems that only want CBOR. > > >From the NETMOD perspective, I am pretty sure CBOR is _not_ added to > the JSON encoding document. The reasons is modularity (see above) and > also the fact that the JSON document is pretty much done and several > other documents depend on it and we won't hold things off for another > N months. > > Whether the CBOR encoding is done in CORE or NETMOD can be discussed. > I guess this is a decision whether this requires more CBOR expertise > or more YANG expertise. Given that this work started being discussed > in CORE, I personally would not mind to leave the work in CORE and to > ensure that NETMOD is kept updated when things become stable (e.g., > the CBOR encoding document goes to WG last call). > > /js > > On Thu, Nov 19, 2015 at 11:00:03AM +0100, peter van der Stok wrote: > > Hi CoOL authors. > > > > I have looked at your section 5, and see an enormous overlap with the > > CoMI section 6. Actually the two proposals are almost completely > > interoperable, with a few exceptions. Much of the CoMI proposal is based > > on the work of Ladislav Lhotka, described in > > draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it > > extensively. In the CoOL draft the yang-json draft is ignored. That is a > > pity because you are redoing much of the work already done in the > > yang-json draft. In the CoMI draft we used the results of yang-json > > draft, exchanged the YANG name by the hash value, and passed it through > > the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant > > solution. > > Below, I have summarized my comparison between CoMI YANG to CBOR and > > CoOL YANG to CBOR. Please check for omissions and mistakes. > > Differences concern Binary byte string and Bits. The CoMI choice of CBOR > > type is derived from yang-json, and I should like to hear the opinion of > > Ladislav on this aspect. > > Other differences concern decimal64, and int; but I expect that is an > > oversight in the CoOL draft. > > A major difference is the encoding of lists and list instances; I > > discuss that in a separate e_mail. > > Given the overlap of work and the need for the expertise of the netmod > > WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and > > uses as much as possible the contents of yang-json draft. Alternatively, > > I can imagine that CBOR mapping is added to the yang-json draft if the > > author, Ladislav Lhotka, and the WGs agree with that. > > > > Greetings, > > > > Peter > > ______________________________________________________________________________ > > Comparison of draft veillette-core cool, denoted with CoOL > > With draft vanderstok-core-comi, denoted with CoMI > > And draft ietf-netmod-yang-json, denoted with yang-json > > Simple YANG type can be : > > Binary byte string: CoMI, major type 2; > > CoOL, major type 0 > > Bits: CoMI, array of text; > > CoOL, major type 0 > > Boolean: CoMI, major type 7 (20,21); > > CoOL, major type 7 (20,21) > > decimal64: CoMI, major type 0 (pos) and > > 1(neg); CoOL major type 0 > > empty: CoMI major type 7(22); > > CoOL major type 7(22) > > enumeration: CoMI, major type 0; > > CoOL major type 0 > > identityref: CoMI, major type 3; > > CoOL major type 3 > > int8, int16, int32, int64: CoMI, major type 0 (pos) and > > 1(neg); CoOL major type 0 > > leafref: CoMI, follows leaf type; > > CoOL follows leaf type > > string: CoMI, major type 3, > > CoOL major type 3 > > uint8, uint16, uint32, uint64: CoMI, major type 0; > > CoOL major type 0 > > > > In netmod-yang-json draft JSON objects are used: > > JSON object := { name: JSON object}, where name is a string. For CoMI > > and CoOL the name can be an integer which is valid for diagnostic JSON > > used for CBOR, giving: > > CBOR object := {integer: CBOR object} > > > > Leaf: > > Yang-json, Name : value, where name is the string identifier of the > > leaf, and value of Simple YANG type > > CoMI: major type 5 containing: uint64, value; CoOL: not defined > > > > Union: > > Yang-json, use corresponding media type for type of value > > CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type > > > > anyxml, > > YANG-json, value can be of any type. > > CoMI, not applicable; CoOL, can be any CBOR type > > > > Anydate, > > Yang-json, follows container > > CoMI, not applicable, CoOL, not applicable > > > > container, > > yang-json, name: JSON object > > CoMI: major type 5; CoOL, major type 5 > > > > leaf-list > > yang-json, name: [ value 1, value 2,鈥︹ > > CoMI, major type 4, CoOL, major type 4 > > > > List > > Yang-json, name:[ JSON object1, JSON object2, 鈥.] > > CoMI, major type 5 of major type 5, CoOL, major type 4 of > > major type 5 > > > > > > > > -- > > Peter van der Stok > > vanderstok consultancy > > mailto: consultancy@vanderstok.org > > > > -- > 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 > ________________________________________________________ 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 Thu Nov 19 05:40:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34D51AD481 for ; Thu, 19 Nov 2015 05:40:41 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBIgPsnQyltv for ; Thu, 19 Nov 2015 05:40:39 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACE91AD49D for ; Thu, 19 Nov 2015 05:40:38 -0800 (PST) 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.325.17; Thu, 19 Nov 2015 13:40: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.0325.019; Thu, 19 Nov 2015 13:40:35 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] YANG list to CBOR mapping Thread-Index: AQHRIrIaNU9q4tL9iE+AdF+qow8vM56jT5XA Date: Thu, 19 Nov 2015 13:40:35 +0000 Message-ID: References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> In-Reply-To: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:kxuwUk3+yIiK9E3wlZd86Fdm8clh0lgD5S1J+PjyP6yHCxEoFr29mann4gDQv5/Y9hlLc0gR/kIDIvH5/rgIHzeEgOHx+dK6ieJVGKF+9OoKgBYEzghnu2qKbHkohsEc508+zW/FEiGpMTdlB4bEQA==; 24:EZ4meOsRdFOHA9X7IY+szBOFr6JBUyYLRY7G5d/Fy+ABqBVxJwQt5srXNETV7ctQf8UeruSp00br03cjpBIc3HUB86Ps8Mh0w5mVDuR983E=; 20:DVLg+N2ndGENEtKQIIMlSph0bz7No20Dn2lt3fpxYxCxzCBW6fTKL61uLtYAzh5qtm6ZxjVPxJhHOBASZDCcQA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 07658B8EA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377424004)(377454003)(13464003)(38414003)(106356001)(189998001)(97736004)(11100500001)(5001770100001)(105586002)(106116001)(15974865002)(99286002)(19580395003)(40100003)(66066001)(5007970100001)(86362001)(5001960100002)(19580405001)(5004730100002)(81156007)(5002640100001)(586003)(122556002)(5003600100002)(10400500002)(2501003)(5008740100001)(74316001)(87936001)(2900100001)(2950100001)(102836003)(15395725005)(561944003)(77096005)(15975445007)(50986999)(76176999)(76576001)(54356999)(6116002)(101416001)(33656002)(3846002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1: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: 19 Nov 2015 13:40:35.7213 (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: "lhotka@nic.cz" Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 13:40:42 -0000 SGkgUGV0ZXINCg0KVGhlIGxpc3QgZXhhbXBsZSBzaG93IHdoeSBDb09MIHByb3Bvc2UgYSBkaXJl Y3QgbWFwcGluZyAoWUFORyAtPiBDQk9SKSBpbnN0ZWFkIG9mIGEgdHdvIHN0ZXBzIG1hcHBpbmcg KFlBTkcgLT4gSlNPTiAtPiBDQk9SKSBhcyBwcm9wb3NlZCBieSBDb01JLg0KDQpUd28gYXNwZWN0 cyBvZiB5b3VyIHByb3Bvc2FsIGZvciBsaXN0cyBhcmUgaW52YWxpZCBpbiBKU09OLg0KLSBUaGUg dXNlIG9mIGFuIGludGVnZXIgYXMgb2JqZWN0IG5hbWUNCi0gVGhlIHVzZSBvZiBhbiBvYmplY3Qg YXMgb2JqZWN0IHZhbHVlDQpTZWUgaHR0cDovL2pzb25saW50LmNvbS8gZm9yIHRlc3RpbmcgY29t cGxpYW5jZS4NCg0KWW91ciBwcm9wb3NlZCBzb2x1dGlvbiBlZmZlY3RpdmVseSBzZWVtIHRvIG1h a2Ugc2Vuc2UgYnV0IHRoaXMgc29sdXRpb24gaXMgcG9zc2libGUgb25seSBpbiB0aGUgY29udGV4 dCBvZiBhIGRpcmVjdCBtYXBwaW5nIChZQU5HIC0+IENCT1IpDQpDb09MIGRpZG4ndCAiaWdub3Jl IHRoZSB5YW5nLWpzb24gZHJhZnQiLCBpdCB1c2UgaXQgYXMgYSB0ZW1wbGF0ZS4NCg0KVGhlIHR3 byBzdGVwcyBtYXBwaW5nIChZQU5HIC0+IEpTT04gLT4gQ0JPUikgZG8gbm90IGFsbG93IHRvIHRh a2UgZnVsbCBhZHZhbnRhZ2Ugb2YgdGhlIHNwZWNpZmljaXRpZXMgb2YgQ0JPUi4NClRoaXMgaXMg dHJ1ZSBmb3IgdGhlIGxpc3QsIHRydWUgZm9yIHRoZSBiaXRzIGRhdGF0eXBlIGFuZCBwcm9iYWJs eSB0cnVlIGZvciBvdGhlciBkYXRhdHlwZXMgbGlrZSAgZW51bWVyYXRpb24gLCBpZGVudGl0eXJl ZiwgaW5zdGFuY2UtaWRlbnRpZmllciwgbGVhZnJlZg0KVGhlIGRpcmVjdCBtYXBwaW5nIHdpbGwg YWxzbyBhbGxvdyB0aGUgdXNlIG9mIHRoZSBjdXJyZW50bHkgZGlzY3Vzc2VkIGRldGVybWluaXN0 aWMgbWFwIGZvciBjb250YWluZXIuDQoNCkkgaG9wZSB0aGlzIHByb3ZpZGUgbW9yZSBiYWNrZ3Jv dW5kIGFib3V0IHdoeSBDb09MIHByb3Bvc2UgYSBkaXJlY3QgbWFwcGluZyBhbmQgdGhlIG5lY2Vz c2l0eSBvZiB0aGlzIGFwcHJvYWNoLg0KDQpBYm91dCB5b3VyIHByb3Bvc2FsIHRvIHN1Ym1pdCB0 aGlzIHdvcmsgdGhlIG5ldG1vZCB3ZywgSSBwZXJzb25hbGx5IHByZWZlciB0byBwZXJmb3JtIGFs bCB0aGlzIHdvcmsgKHRoZSA0IG9yIDYgZHJhZnRzKSB1bmRlciB0aGUgY29yZSBncm91cC4NClRo ZSBDT1JFIGdyb3VwIGlzIHdoZXJlIHRoZSBDQk9SIGV4cGVydGlzZSBpcyB3aGljaCBpcyBjcml0 aWNhbCBmb3IgdGhpcyBkcmFmdC4gDQoNClJlZ2FyZHMsDQoNCk1pY2hlbCBWZWlsbGV0dGUNClN5 c3RlbSBBcmNoaXRlY3R1cmUgRGlyZWN0b3INClRyaWxsaWFudCBJbmMuDQpUZWw6IDQ1MC0zNzUt MDU1NiBleHQuIDIzNw0KbWljaGVsLnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tDQp3d3cudHJp bGxpYW50aW5jLmNvbSANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29y ZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBldGVyIHZhbiBk ZXIgU3Rvaw0KU2VudDogTm92ZW1iZXItMTktMTUgNTowNiBBTQ0KVG86IENvcmUgPGNvcmVAaWV0 Zi5vcmc+DQpDYzogbGhvdGthQG5pYy5jeg0KU3ViamVjdDogW2NvcmVdIFlBTkcgbGlzdCB0byBD Qk9SIG1hcHBpbmcNCg0KSGkgQ29PTCBhdXRob3JzLA0KDQpUaGlzIGVfbWFpbCBjb21wbGVtZW50 cyBteSBlYXJsaWVyIGUtbWFpbCBvbiBZQU5HIHRvIENCT1IgbWFwcGluZywgYW5kIGV4cGxhaW5z IHRoZSBwcm9wb3NlZCBsaXN0IGVuY29kaW5nLg0KDQpCb3RoIHRoZSBkcmFmdCB5YW5nLWpzb24g YW5kIHRoZSBDb09MIGRyYWZ0IGVuY29kZSBhIGxpc3QgYXMgYW4gYXJyYXkuIA0KSW4gdGhlIHlh bmctanNvbiBjYXNlIGFzIGEgSlNPTiBhcnJheSwgYW5kIGluIHRoZSBDb09MIGNhc2UgYXMgbWFq b3IgdHlwZSA0IG9mIG1ham9yIHR5cGUgNSBvYmplY3RzLg0KVGhpcyBlbmNvZGluZyBwcmV2ZW50 cyB0aGUgc2VsZWN0aW9uIG9mIGxpc3QgaW5zdGFuY2VzIG9uIHRoZSBiYXNpcyBvZiB0aGUga2V5 IHZhbHVlcyBmcm9tIHRoZSBwYXlsb2FkIGFsb25lLiBJbiBDb01JIHRoZSBsaXN0IGlzIGVuY29k ZWQgYXMgYSBtYWpvciB0eXBlIDUgb2YgbWFqb3IgdHlwZSA1IG9iamVjdHMuIFRoaXMgZGV2aWF0 aW9uIGZyb20gdGhlIHlhbmctanNvbiBtYXBwaW5nIGlzIG1vdGl2YXRlZCBieSB0aGUgd2lzaCB0 byB0cmFuc3BvcnQgaW5kaXZpZHVhbCBsaXN0IGluc3RhbmNlcyBhbmQgaWRlbnRpZnkgdGhlIGlu c3RhbmNlcyBpbiB0aGUgcGF5bG9hZCBmcm9tIHRoZSBrZXkgdmFsdWVzLiBUaGlzIGlzIGVzcGVj aWFsbHkgaW1wb3J0YW50IGluIGNhc2Ugb2YgUEFUQ0ggb3BlcmF0aW9uIG9uIGxpc3QgaW5zdGFu Y2VzLg0KVHdvIGNhc2VzIGFyZSB0byBiZSBsb29rZWQgYXQ6ICgxKSB0aGUgbGlzdCBkZWZpbml0 aW9uIHNwZWNpZmllcyBvbmUgb3IgbW9yZSBrZXkgZWxlbWVudHMsIGFuZCAoMikgdGhlIGxpc3Qg ZGVmaW5pdGlvbiBkb2VzIG5vdCBzcGVjaWZ5IGEga2V5IGVsZW1lbnQuIFdlIHdpbGwgc3RhcnQg d2l0aCBhIGxpc3QgY29udGFpbmluZyBrZXkgZWxlbWVudHMuDQpJdCBpcyB0aGUgd2lzaCB0byB0 cmFuc3BvcnQgb25seSB0aG9zZSBsaXN0IGVsZW1lbnRzIHdpdGggYSB1bmlxdWUga2V5IHZhbHVl LCBlaXRoZXIgdG8gc3VwcG9ydCBhIFBBVENIIG9yIGEgRkVUQ0ggY29tbWFuZC4gVGhlcmVmb3Jl IGl0IGlzIHJlcXVpcmVkIHRoYXQgdGhlIHBheWxvYWQgYWxsb3dzIHRoZSBzZWxlY3Rpb24gYW5k IGlkZW50aWZpY2F0aW9uIG9mIHRoZXNlIGxpc3QgZWxlbWVudCBvbiB0aGUgYmFzaXMgb2YgdGhl aXIga2V5IHZhbHVlcy4gVXNpbmcgdGhlIGRpYWdub3N0aWMgSlNPTiBub3RhdGlvbiB1c2VkIGZv ciBDQk9SIGRpYWdub3N0aWNzLCB0aGUgcGF5bG9hZCBjb250YWluaW5nIGEgbnVtYmVyIG9mIGVs ZW1lbnRzIHdpdGgga2V5IHZhbHVlcyBzaG91bGQgbG9vayBsaWtlIGEgSlNPTiBvYmplY3Qgd2l0 aCB0aGUgc3RydWN0dXJlIGxpc3QtbmFtZToge2tleTogdmFsdWV9LiBCb3RoIGtleSBhbmQgdmFs dWUgYXJlIGNvbXBvc2VkIG9mIEpTT04gb2JqZWN0cyBzZXBhcmF0ZWQgYnkgY29tbWFzLiBGb3Ig ZXhhbXBsZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIFlBTkcgbGlzdCBzcGVjaWZpY2F0aW9uOg0K bW9kdWxlIGZvbyB7DQogICAgIG5hbWVzcGFjZSBodHRwOi8vZXhhbXBsZS5jb20vYm9vazsNCiAg ICAgcHJlZml4IOKAnGZv4oCdOw0KICAgICByZXZpc2lvbiAgMjAxNS0wNi0wNzsNCg0KICAgIGxp c3QgQiB7DQogICAgICAga2V5IOKAnGtleTEga2V5MuKAnTsNCiAgICAgICBsZWFmIGtleTEge3R5 cGUgc3RyaW5nO30NCiAgICAgICBsZWFmIGtleTIge3R5cGUgc3RyaW5nO30NCiAgICAgICBsZWFm IGNvbGwge3R5cGUgaW50MzI7fQ0KICAgICAgIGxlYWYgY291bnRlciB7dHlwZSBpbnQzMjt9DQog ICAgfQ0KfQ0KDQpDb25zaWRlciB0aGUgdHJhbnNwb3J0IG9mIHR3byBpbnN0YW5jZXMgc3BlY2lm aWVkIGJ5IDzigJxrZXkx4oCdID0g4oCcYm9vazHigJ0sIOKAnGtleTLigJ0gPSDigJxhdXRob3Iy 4oCdPiBhbmQgYnkgPOKAnGtleTHigJ0gPSDigJxib29rNeKAnSwg4oCca2V5MuKAnSA9IOKAnGF1 dGhvcjPigJ0+IG91dCBvZiBhIGxhcmdlciBzZXQgb2YgaW5zdGFuY2VzLiBUaGUgcmVwcmVzZW50 YXRpb24gaXMgZGlmZmVyZW50IGZyb20gdGhlIHlhbmctanNvbiBvbmUgZm9yIHRoZSByZWFzb25z IGV4cGxhaW5lZCBhYm92ZS4NCg0KVGhlIHBheWxvYWQgd2lsbCBsb29rIGxpa2U6DQp7IkIiIDp7 DQogICAgIHsia2V5MSIgOiAiYm9vazEiLCAia2V5MiIgOiAiYXV0aG9yMiJ9IDoNCiAgICAgeyJj b2xsIiA6IDUwMCwgImNvdW50ZXIiOiA2Nn0gLA0KICAgICB7ImtleTEiIDogImJvb2s1IiwgImtl eTIiIDogImF1dGhvcjMifSA6DQogICAgIHsiY29sbCIgOiA0NDQsICJjb3VudGVyIjogMTF9DQog ICAgIH0NCn0NCg0KDQpXaGljaCB0cmFuc2xhdGVkIHRvIENCT1IgeWllbGRzOg0KDQphMSAgICAg ICAgICAgICAgICAgICAgICAgICAjIG1hcCgxKQ0KICAgIDYxICAgICAgICAgICAgICAgICAgICAg ICMgdGV4dCgxKQ0KICAgICAgIDQyICAgICAgICAgICAgICAgICAgICMgIkIiDQogICAgYTIgICAg ICAgICAgICAgICAgICAgICAgIyBtYXAoMikNCiAgICAgICBhMiAgICAgICAgICAgICAgICAgICAj IG1hcCgyKQ0KICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4dCg0KQ0KICAgICAgICAg ICAgIDZiNjU3OTMxICAgICAgICMgImtleTEiDQogICAgICAgICAgNjUgICAgICAgICAgICAgICAg IyB0ZXh0KDUpDQogICAgICAgICAgICAgNjI2ZjZmNmIzMSAgICAgIyAiYm9vazEiDQogICAgICAg ICAgNjQgICAgICAgICAgICAgICAgIyB0ZXh0KDQpDQogICAgICAgICAgICAgNmI2NTc5MzIgICAg ICAgIyAia2V5MiINCiAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCiAgICAg ICAgICAgICA2MTc1NzQ2ODZmNzIzMiAjICJhdXRob3IyIg0KICAgICAgIGEyICAgICAgICAgICAg ICAgICAgICMgbWFwKDIpDQogICAgICAgICAgNjQgICAgICAgICAgICAgICAgIyB0ZXh0KDQpDQog ICAgICAgICAgICAgNjM2ZjZjNmMgICAgICAgIyAiY29sbCINCiAgICAgICAgICAxOSAwMWY0ICAg ICAgICAgICAjIHVuc2lnbmVkKDUwMCkNCiAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRl eHQoNykNCiAgICAgICAgICAgICA2MzZmNzU2ZTc0NjU3MiAjICJjb3VudGVyIg0KICAgICAgICAg IDE4IDQyICAgICAgICAgICAgICMgdW5zaWduZWQoNjYpDQogICAgICAgYTIgICAgICAgICAgICAg ICAgICAgIyBtYXAoMikNCiAgICAgICAgICA2NCAgICAgICAgICAgICAgICAjIHRleHQoNCkNCiAg ICAgICAgICAgICA2YjY1NzkzMSAgICAgICAjICJrZXkxIg0KICAgICAgICAgIDY1ICAgICAgICAg ICAgICAgICMgdGV4dCg1KQ0KICAgICAgICAgICAgIDYyNmY2ZjZiMzUgICAgICMgImJvb2s1Ig0K ICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4dCg0KQ0KICAgICAgICAgICAgIDZiNjU3 OTMyICAgICAgICMgImtleTIiDQogICAgICAgICAgNjcgICAgICAgICAgICAgICAgIyB0ZXh0KDcp DQogICAgICAgICAgICAgNjE3NTc0Njg2ZjcyMzMgIyAiYXV0aG9yMyINCiAgICAgICBhMiAgICAg ICAgICAgICAgICAgICAjIG1hcCgyKQ0KICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4 dCg0KQ0KICAgICAgICAgICAgIDYzNmY2YzZjICAgICAgICMgImNvbGwiDQogICAgICAgICAgMTkg MDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQogICAgICAgICAgNjcgICAgICAgICAgICAg ICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjM2Zjc1NmU3NDY1NzIgIyAiY291bnRlciINCiAg ICAgICAgICAwYiAgICAgICAgICAgICAgICAjIHVuc2lnbmVkKDExKQ0KDQpUaGUgY29ycmVzcG9u ZGluZyB5YW5nLWpzb24gZHJhZnQgZW5jb2RpbmcgLSB0aGF0IGFsbG93cyB0cmFuc3BvcnQgb2Yg YSBzZWxlY3Rpb24gb2YgaW5zdGFuY2VzLSBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBrZXkgZmllbGRz IGFuZCB3b3VsZCBoYXZlIGxvb2tlZCBsaWtlOg0KDQp7IkIiIDogWw0KICAgICB7ImtleTEiIDog ImJvb2sxIiwNCiAgICAgICAia2V5MiIgOiAiYXV0aG9yMuKAnSwNCiAgICAgICAgImNvbGwiIDog NTAwLA0KICAgICAgICAiY291bnRlciI6IDY2DQogICAgICB9ICwNCiAgICAgeyJrZXkxIiA6ICJi b29rNSIsDQogICAgICAgImtleTIiIDogImF1dGhvcjMiLA0KICAgICAgICJjb2xsIiA6IDQ0NCwN CiAgICAgICAiY291bnRlciI6IDExLA0KICAgICB9DQogICBdDQp9DQoNClN1cHBvc2UgdGhlcmUg YXJlIG5vIGtleSBlbGVtZW50cyBzcGVjaWZpZWQuIEluIHRoYXQgY2FzZSBpdCBpcyBpbXBvc3Np YmxlIHRvIHNwZWNpZnkgdGhlIHdhbnRlZCBsaXN0IGVsZW1lbnRzLCBhbmQgYWx3YXlzIHRoZSB3 aG9sZSBsaXN0IG11c3QgYmUgdHJhbnNwb3J0ZWQuIEluIHRoZSBjYXNlIG9mIGEgbGlzdCB3aXRo b3V0IGtleSBzcGVjaWZpY2F0aW9uIGlzIGlzIGJlc3QgdG8gdXNlIG1ham9yIHR5cGUgNCBjb21w b3NlZCBvZiBtYWpvciB0eXBlIDUgdG8gdHJhbnNwb3J0IHRoZSBsaXN0LCBhcyBpcyBzcGVjaWZp ZWQgaW4geWFuZy1qc29uIGRyYWZ0Lg0KDQpDb25zaWRlciB0aGUgZm9sbG93aW5nIFlBTkcgbGlz dA0KDQpNb2R1bGUgZm9vew0KICAgICBOYW1lc3BhY2UgaHR0cDovL2V4YW1wbGUuY29tL2Jvb2s7 DQogICAgIFByZWZpeCDigJxib+KAnQ0KICAgICBSZXZpc2lvbiAgMjAxNS0wNi03DQpMaXN0IEIg ew0KICAgIExlYWYgdGl0bGUge3R5cGUgc3RyaW5nO30NCiAgICBMZWFmIGF1dGhvciB7dHlwZSBz dHJpbmc7fQ0KICAgIExlYWYgY29sbCB7dHlwZSBpbnQzMn0NCiAgICBMZWFmIGNvdW50ZXIge3R5 cGUgaW50MzJ9DQogICAgfQ0KfQ0KDQpTdXBwb3NlIHRoZSBsaXN0IGNvbnRhaW5zIHR3byBlbGVt ZW50cy4gVGhlIHRyYW5zcG9ydCBwYXlsb2FkIG9mIHRoZSB0d28gZWxlbWVudHMgbG9va3MgbGlr ZToNCg0KeyJCIiA6Ww0KICAgICB7InRpdGxlIiA6ICJib29rMSIsICJhdXRob3IiIDogImF1dGhv cjIiLCAiY29sbCIgOiA1MDAsICJjb3VudGVyIjogDQo2Nn0gLA0KICAgICB7InRpdGxlIiA6ICJi b29rNSIsICJhdXRob3IiIDogImF1dGhvcjMiLCAg4oCcY29sbCIgOiA0NDQsICJjb3VudGVyIjog DQoxMX0NCiAgICAgXQ0KfQ0KDQpUaGlzIHBheWxvYWQgaXMgaWRlbnRpY2FsIHRvIHRoZSB5YW5n LWpzb24gcGF5bG9hZC4NCldoaWNoIHlpZWxkcyB0aGUgY29ycmVzcG9uZGluZyBDQk9SIGNvZGUu DQoNCmExICAgICAgICAgICAgICAgICAgICAgICAgICMgbWFwKDEpDQogICAgNjEgICAgICAgICAg ICAgICAgICAgICAgIyB0ZXh0KDEpDQogICAgICAgNDIgICAgICAgICAgICAgICAgICAgIyAiQiIN CiAgICA4MiAgICAgICAgICAgICAgICAgICAgICAjIGFycmF5KDIpDQogICAgICAgYTQgICAgICAg ICAgICAgICAgICAgIyBtYXAoNCkNCiAgICAgICAgICA2NSAgICAgICAgICAgICAgICAjIHRleHQo NSkNCiAgICAgICAgICAgICA3NDY5NzQ2YzY1ICAgICAjICJ0aXRsZSINCiAgICAgICAgICA2NSAg ICAgICAgICAgICAgICAjIHRleHQoNSkNCiAgICAgICAgICAgICA2MjZmNmY2YjMxICAgICAjICJi b29rMSINCiAgICAgICAgICA2NiAgICAgICAgICAgICAgICAjIHRleHQoNikNCiAgICAgICAgICAg ICA2MTc1NzQ2ODZmNzIgICAjICJhdXRob3IiDQogICAgICAgICAgNjcgICAgICAgICAgICAgICAg IyB0ZXh0KDcpDQogICAgICAgICAgICAgNjE3NTc0Njg2ZjcyMzIgIyAiYXV0aG9yMiINCiAgICAg ICAgICA2NCAgICAgICAgICAgICAgICAjIHRleHQoNCkNCiAgICAgICAgICAgICA2MzZmNmM2YyAg ICAgICAjICJjb2xsIg0KICAgICAgICAgIDE5IDAxZjQgICAgICAgICAgICMgdW5zaWduZWQoNTAw KQ0KICAgICAgICAgIDY3ICAgICAgICAgICAgICAgICMgdGV4dCg3KQ0KICAgICAgICAgICAgIDYz NmY3NTZlNzQ2NTcyICMgImNvdW50ZXIiDQogICAgICAgICAgMTggNDIgICAgICAgICAgICAgIyB1 bnNpZ25lZCg2NikNCiAgICAgICBhNCAgICAgICAgICAgICAgICAgICAjIG1hcCg0KQ0KICAgICAg ICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4dCg1KQ0KICAgICAgICAgICAgIDc0Njk3NDZjNjUg ICAgICMgInRpdGxlIg0KICAgICAgICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4dCg1KQ0KICAg ICAgICAgICAgIDYyNmY2ZjZiMzUgICAgICMgImJvb2s1Ig0KICAgICAgICAgIDY2ICAgICAgICAg ICAgICAgICMgdGV4dCg2KQ0KICAgICAgICAgICAgIDYxNzU3NDY4NmY3MiAgICMgImF1dGhvciIN CiAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCiAgICAgICAgICAgICA2MTc1 NzQ2ODZmNzIzMyAjICJhdXRob3IzIg0KICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4 dCg0KQ0KICAgICAgICAgICAgIDYzNmY2YzZjICAgICAgICMgImNvbGwiDQogICAgICAgICAgMTkg MDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQogICAgICAgICAgNjcgICAgICAgICAgICAg ICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjM2Zjc1NmU3NDY1NzIgIyAiY291bnRlciINCiAg ICAgICAgICAwYiAgICAgICAgICAgICAgICAjIHVuc2lnbmVkKDExKQ0KDQoNCi0tDQpQZXRlciB2 YW4gZGVyIFN0b2sNCnZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCm1haWx0bzogbWFpbHRvOmNvbnN1 bHRhbmN5QHZhbmRlcnN0b2sub3JnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KbWFpbHRvOmNvcmVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Thu Nov 19 05:54:53 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE78B1AC3CB for ; Thu, 19 Nov 2015 05:54:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvVRCgiopOEd for ; Thu, 19 Nov 2015 05:54:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.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 0A1281B29B0 for ; Thu, 19 Nov 2015 05:54:48 -0800 (PST) Received: from BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) by BLUPR06MB307.namprd06.prod.outlook.com (10.141.23.147) with Microsoft SMTP Server (TLS) id 15.1.325.17; Thu, 19 Nov 2015 13:54:46 +0000 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.325.17; Thu, 19 Nov 2015 13:54:45 +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.0325.019; Thu, 19 Nov 2015 13:54:44 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] YANG to CBOR mapping Thread-Index: AQHRIrFRDohJFilcHkWMJpxQ90rIt56jTpSA Date: Thu, 19 Nov 2015 13:54:44 +0000 Message-ID: References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> In-Reply-To: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:ZeAu0tGTwPs3SN42st1oBP8nPcl5f9CBNtSp/2OV8nOaakJWkFWz/oYGfOPhUJFYQFMYNZFZ0g+5z5sWq/JXoMPMQ2hg168iemL3z2OzYW3CqplcwMH+NKgF0jERyvl/AAcLC456Ckjkcob1mROZLA==; 24:Kx8aNI9DoGOM/sJmGYrSuADfMXHbXG/jXsIkpsL9MfeYLOoQTPaXRS6qxubCrxuBqVjIGccNkAZD8I7JsBQ24zGtxdaL7WutjhZ3j8tWl9k=; 20:RhQnaZ+LthowLFi0x+AKzarqdfxVkKiMHkTzbYVdWMsTCyhGEomVsIEJlxGQE3Kc3ISoL6q+oaROVUERWyMfUw== 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:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 07658B8EA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(66066001)(5008740100001)(5002640100001)(5007970100001)(5003600100002)(76576001)(586003)(15975445007)(101416001)(87936001)(5004730100002)(76176999)(50986999)(2950100001)(6116002)(3846002)(2900100001)(54356999)(77096005)(2501003)(102836003)(33656002)(86362001)(10400500002)(92566002)(122556002)(99286002)(74316001)(106356001)(5001960100002)(40100003)(189998001)(81156007)(105586002)(106116001)(19580405001)(97736004)(5001770100001)(19580395003)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2015 13:54:44.8319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-Microsoft-Exchange-Diagnostics: 1; BLUPR06MB307; 2:HhojDf7BwPfzFxz4Tjwp21YrbrBT5+H0iGm0RVK9Sgh/7DBl1d6RVyucuT+4b88Z4SfVmgRvJJ/uHFRrcop7zIsAAy60tH5ayfO7yESHBOzQ6sznP5R0PLuraOPYCFq01a0lTZMBalK5q2htiXhqLjzbxNHl2FyHje8OKY02IgU=; 23:C0C2aB0OFQqSBOYdK7flyahQOkXA8ascpX2s7Mup6Q8YqA5F/4tQiy+CRbQYNgASOvrjJbmjWqOJI/atU+AkvZHUJKGlb4gqVn4yhn8bLmG3oljSZwM2MZcgLsal7AjmG18SzVhJFp0cUvzU2iMzLUbkR6jX2qvNnzY37UeEqYCgtif7qrxjOJKfJwgMUTKn X-OriginatorOrg: trilliantinc.com Archived-At: Cc: "lhotka@nic.cz" Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 13:54:52 -0000 SGkgUGV0ZXINCg0KV291bGQgeW91IHBsZWFzZSBleHBsYWluIHlvdXIgc3BlY2lmaWMgY29uY2Vy bnMgYWJvdXQgdGhlIFlBTkcgdG8gQ0JPUiBtYXBwaW5nIG9mIGRlY2ltYWw2ND8NCg0KWUFORyBk ZWZpbmUgZGVjaW1hbCBhcyBmb2xsb3c6DQogICBUaGUgZGVjaW1hbDY0IHR5cGUgcmVwcmVzZW50 cyBhIHN1YnNldCBvZiB0aGUgcmVhbCBudW1iZXJzLCB3aGljaCBjYW4NCiAgIGJlIHJlcHJlc2Vu dGVkIGJ5IGRlY2ltYWwgbnVtZXJhbHMuIFRoZSB2YWx1ZSBzcGFjZSBvZiBkZWNpbWFsNjQgaXMN CiAgIHRoZSBzZXQgb2YgbnVtYmVycyB0aGF0IGNhbiBiZSBvYnRhaW5lZCBieSBtdWx0aXBseWlu ZyBhIDY0LWJpdA0KICAgc2lnbmVkIGludGVnZXIgYnkgYSBuZWdhdGl2ZSBwb3dlciBvZiB0ZW4s IGkuZS4sIGV4cHJlc3NpYmxlIGFzDQogICAiaSB4IDEwXi1uIiB3aGVyZSBpIGlzIGFuIGludGVn ZXI2NCBhbmQgbiBpcyBhbiBpbnRlZ2VyIGJldHdlZW4gMSBhbmQNCiAgIDE4LCBpbmNsdXNpdmVs eS4NCg0KQ29PTCBwcm9wb3NlIHRoZSB1c2Ugb2YgQ0JPUiB1bnNpZ25lZCBpbnRlZ2VyDQoNCiAg IExlYWZzIG9mIHR5cGUgZGVjaW1hbDY0IE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgdW5z aWduZWQgaW50ZWdlcg0KICAgZGF0YSBpdGVtIChtYWpvciB0eXBlIDApLg0KICAgRGVmaW5pdGlv biBleGFtcGxlIFtSRkM3MzE3XToNCg0KICAgbGVhZiBteS1kZWNpbWFsIHsNCiAgICAgdHlwZSBk ZWNpbWFsNjQgew0KICAgICAgIGZyYWN0aW9uLWRpZ2l0cyAyOw0KICAgICAgIHJhbmdlICIxIC4u IDMuMTQgfCAxMCB8IDIwLi5tYXgiOw0KICAgICB9DQogICB9DQoNCiAgIFRleHR1YWwgZm9ybTog MjU3IChSZXByZXNlbnRzIGRlY2ltYWwgdmFsdWUgMi41NykNCg0KICAgQ0JPUiBlbmNvZGluZzog MTkgMDEwMQ0KDQpXaGF0IGlzIHdyb25nIGluIHRoaXMgbWFwcGluZz8NCg0KUmVnYXJkcywNCg0K TWljaGVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIFttYWlsdG86 Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgcGV0ZXIgdmFuIGRlciBTdG9rDQpT ZW50OiBOb3ZlbWJlci0xOS0xNSA1OjAwIEFNDQpUbzogQ29yZSA8Y29yZUBpZXRmLm9yZz4NCkNj OiBsaG90a2FAbmljLmN6DQpTdWJqZWN0OiBbY29yZV0gWUFORyB0byBDQk9SIG1hcHBpbmcNCg0K SGkgQ29PTCBhdXRob3JzLg0KDQpJIGhhdmUgbG9va2VkIGF0IHlvdXIgc2VjdGlvbiA1LCBhbmQg c2VlIGFuIGVub3Jtb3VzIG92ZXJsYXAgd2l0aCB0aGUgQ29NSSBzZWN0aW9uIDYuIEFjdHVhbGx5 IHRoZSB0d28gcHJvcG9zYWxzIGFyZSBhbG1vc3QgY29tcGxldGVseSBpbnRlcm9wZXJhYmxlLCB3 aXRoIGEgZmV3IGV4Y2VwdGlvbnMuIE11Y2ggb2YgdGhlIENvTUkgcHJvcG9zYWwgaXMgYmFzZWQg b24gdGhlIHdvcmsgb2YgTGFkaXNsYXYgTGhvdGthLCBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1u ZXRtb2QteWFuZy1qc29uLiBDb01JIHJlZmVycyB0byB0aGlzIGRyYWZ0IGFuZCB1c2VzIGl0IGV4 dGVuc2l2ZWx5LiBJbiB0aGUgQ29PTCBkcmFmdCB0aGUgeWFuZy1qc29uIGRyYWZ0IGlzIGlnbm9y ZWQuIFRoYXQgaXMgYSBwaXR5IGJlY2F1c2UgeW91IGFyZSByZWRvaW5nIG11Y2ggb2YgdGhlIHdv cmsgYWxyZWFkeSBkb25lIGluIHRoZSB5YW5nLWpzb24gZHJhZnQuIEluIHRoZSBDb01JIGRyYWZ0 IHdlIHVzZWQgdGhlIHJlc3VsdHMgb2YgeWFuZy1qc29uIGRyYWZ0LCBleGNoYW5nZWQgdGhlIFlB TkcgbmFtZSBieSB0aGUgaGFzaCB2YWx1ZSwgYW5kIHBhc3NlZCBpdCB0aHJvdWdoIHRoZSBkaWFn bm9zdGljIEpTT04gdG8gQ0JPUiB0cmFuc2xhdG9yLiBRdWl0ZSBhIHNhdGlzZmFjdG9yeSBhbmQg ZWxlZ2FudCBzb2x1dGlvbi4NCkJlbG93LCBJIGhhdmUgc3VtbWFyaXplZCBteSBjb21wYXJpc29u IGJldHdlZW4gQ29NSSBZQU5HIHRvIENCT1IgYW5kIENvT0wgWUFORyB0byBDQk9SLiBQbGVhc2Ug Y2hlY2sgZm9yIG9taXNzaW9ucyBhbmQgbWlzdGFrZXMuDQpEaWZmZXJlbmNlcyBjb25jZXJuIEJp bmFyeSBieXRlIHN0cmluZyBhbmQgQml0cy4gVGhlIENvTUkgY2hvaWNlIG9mIENCT1IgdHlwZSBp cyBkZXJpdmVkIGZyb20geWFuZy1qc29uLCBhbmQgSSBzaG91bGQgbGlrZSB0byBoZWFyIHRoZSBv cGluaW9uIG9mIExhZGlzbGF2IG9uIHRoaXMgYXNwZWN0Lg0KT3RoZXIgZGlmZmVyZW5jZXMgY29u Y2VybiBkZWNpbWFsNjQsIGFuZCBpbnQ7IGJ1dCBJIGV4cGVjdCB0aGF0IGlzIGFuIG92ZXJzaWdo dCBpbiB0aGUgQ29PTCBkcmFmdC4NCkEgbWFqb3IgZGlmZmVyZW5jZSBpcyB0aGUgZW5jb2Rpbmcg b2YgbGlzdHMgYW5kIGxpc3QgaW5zdGFuY2VzOyBJIGRpc2N1c3MgdGhhdCBpbiBhIHNlcGFyYXRl IGVfbWFpbC4NCkdpdmVuIHRoZSBvdmVybGFwIG9mIHdvcmsgYW5kIHRoZSBuZWVkIGZvciB0aGUg ZXhwZXJ0aXNlIG9mIHRoZSBuZXRtb2QgV0csIEkgcmVjb21tZW5kIHRoYXQgYSBZQU5HIENCT1Ig ZHJhZnQgaXMgc3VibWl0dGVkIHRvIHRoZSBuZXRtb2Qgd2cgYW5kIHVzZXMgYXMgbXVjaCBhcyBw b3NzaWJsZSB0aGUgY29udGVudHMgb2YgeWFuZy1qc29uIGRyYWZ0LiBBbHRlcm5hdGl2ZWx5LCBJ IGNhbiBpbWFnaW5lIHRoYXQgQ0JPUiBtYXBwaW5nIGlzIGFkZGVkIHRvIHRoZSB5YW5nLWpzb24g ZHJhZnQgaWYgdGhlIGF1dGhvciwgTGFkaXNsYXYgTGhvdGthLCBhbmQgdGhlIFdHcyBhZ3JlZSB3 aXRoIHRoYXQuDQoNCkdyZWV0aW5ncywNCg0KUGV0ZXINCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Q29tcGFyaXNvbiBvZiBkcmFmdCB2ZWlsbGV0dGUtY29yZSBjb29sLCBkZW5vdGVkIHdpdGggQ29P TCBXaXRoIGRyYWZ0IHZhbmRlcnN0b2stY29yZS1jb21pLCBkZW5vdGVkIHdpdGggQ29NSSBBbmQg ZHJhZnQgaWV0Zi1uZXRtb2QteWFuZy1qc29uLCBkZW5vdGVkIHdpdGggeWFuZy1qc29uIFNpbXBs ZSBZQU5HIHR5cGUgY2FuIGJlIDoNCkJpbmFyeSBieXRlIHN0cmluZzogICAgICAgICAgICAgICAg ICAgQ29NSSwgbWFqb3IgdHlwZSAyOyAgICAgICAgICAgICAgICANCiAgICAgICAgICBDb09MLCAg bWFqb3IgdHlwZSAwDQpCaXRzOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvTUks IGFycmF5IG9mIHRleHQ7ICAgICAgICAgICAgICAgDQogICAgICAgICAgQ29PTCwgbWFqb3IgdHlw ZSAwDQpCb29sZWFuOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvTUksIG1ham9yIHR5 cGUgNyAoMjAsMjEpOyAgICAgICAgDQogICAgICAgICAgQ29PTCwgbWFqb3IgdHlwZSA3ICgyMCwy MSkNCmRlY2ltYWw2NDogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29NSSwgbWFqb3IgdHlw ZSAwIChwb3MpIGFuZCANCjEobmVnKTsgICAgICAgIENvT0wgbWFqb3IgdHlwZSAwDQplbXB0eTog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENvTUkgbWFqb3IgdHlwZSA3KDIyKTsgICAg ICAgICAgICAgDQogICAgICAgICAgQ29PTCBtYWpvciB0eXBlIDcoMjIpDQplbnVtZXJhdGlvbjog ICAgICAgICAgICAgICAgICAgICAgICAgIENvTUksIG1ham9yIHR5cGUgMDsgICAgICAgICAgICAg ICAgDQogICAgICAgICAgQ29PTCBtYWpvciB0eXBlIDANCiAgaWRlbnRpdHlyZWY6ICAgICAgICAg ICAgICAgICAgICAgICAgIENvTUksIG1ham9yIHR5cGUgMzsgICAgICAgICAgICAgICAgDQogICAg ICAgICAgIENvT0wgbWFqb3IgdHlwZSAzDQogIGludDgsIGludDE2LCBpbnQzMiwgaW50NjQ6ICAg ICAgICAgICBDb01JLCBtYWpvciB0eXBlIDAgKHBvcykgYW5kIA0KMShuZWcpOyAgICAgICAgIENv T0wgbWFqb3IgdHlwZSAwDQogIGxlYWZyZWY6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBD b01JLCBmb2xsb3dzIGxlYWYgdHlwZTsgICAgICAgICAgIA0KICAgICAgICAgICBDb09MIGZvbGxv d3MgbGVhZiB0eXBlDQogIHN0cmluZzogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb01J LCBtYWpvciB0eXBlIDMsICAgICAgICAgICAgICAgIA0KICAgICAgICAgICBDb09MIG1ham9yIHR5 cGUgMw0KICB1aW50OCwgdWludDE2LCB1aW50MzIsIHVpbnQ2NDogICAgICAgQ29NSSwgbWFqb3Ig dHlwZSAwOyAgICAgICAgICAgICAgICANCiAgICAgICAgICAgQ29PTCBtYWpvciB0eXBlIDANCg0K SW4gbmV0bW9kLXlhbmctanNvbiBkcmFmdCAgSlNPTiBvYmplY3RzIGFyZSB1c2VkOg0KSlNPTiBv YmplY3QgOj0geyBuYW1lOiBKU09OIG9iamVjdH0sIHdoZXJlIG5hbWUgaXMgYSBzdHJpbmcuIEZv ciBDb01JIGFuZCBDb09MIHRoZSBuYW1lIGNhbiBiZSBhbiBpbnRlZ2VyIHdoaWNoIGlzIHZhbGlk IGZvciBkaWFnbm9zdGljIEpTT04gdXNlZCBmb3IgQ0JPUiwgZ2l2aW5nOg0KQ0JPUiBvYmplY3Qg Oj0ge2ludGVnZXI6IENCT1Igb2JqZWN0fQ0KDQpMZWFmOg0KWWFuZy1qc29uLCAgTmFtZSA6IHZh bHVlLCB3aGVyZSBuYW1lIGlzIHRoZSBzdHJpbmcgaWRlbnRpZmllciBvZiB0aGUgbGVhZiwgYW5k IHZhbHVlIG9mIFNpbXBsZSBZQU5HIHR5cGUNCkNvTUk6IG1ham9yIHR5cGUgNSBjb250YWluaW5n OiB1aW50NjQsIHZhbHVlOyAgICAgIENvT0w6IG5vdCBkZWZpbmVkDQoNClVuaW9uOg0KWWFuZy1q c29uLCAgdXNlIGNvcnJlc3BvbmRpbmcgbWVkaWEgdHlwZSBmb3IgdHlwZSBvZiB2YWx1ZSBDb01J LCB1c2UgY29ycmVzcG9uZGluZyBDQk9SIHR5cGU7IENvT0wsIHVzZSBjb3JyZXNwb25kaW5nIENC T1IgdHlwZQ0KDQphbnl4bWwsDQpZQU5HLWpzb24sIHZhbHVlIGNhbiBiZSBvZiBhbnkgdHlwZS4N CkNvTUksIG5vdCBhcHBsaWNhYmxlOyBDb09MLCBjYW4gYmUgYW55IENCT1IgdHlwZQ0KDQpBbnlk YXRlLA0KWWFuZy1qc29uLCBmb2xsb3dzIGNvbnRhaW5lcg0KQ29NSSwgbm90IGFwcGxpY2FibGUs ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29PTCwgbm90IGFwcGxpY2FibGUNCg0KY29udGFp bmVyLA0KeWFuZy1qc29uLAkgbmFtZTogIEpTT04gb2JqZWN0DQpDb01JOiBtYWpvciB0eXBlIDU7 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb09MLCBtYWpvciB0eXBlIDUNCg0KbGVhZi1s aXN0DQp5YW5nLWpzb24sIG5hbWU6IFsgdmFsdWUgMSwgdmFsdWUgMizigKbigKZdDQpDb01JLCBt YWpvciB0eXBlIDQsICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDb09MLCBtYWpvciB0eXBl IDQNCg0KTGlzdA0KWWFuZy1qc29uLCBuYW1lOlsgSlNPTiBvYmplY3QxLCBKU09OIG9iamVjdDIs IOKApi5dDQpDb01JLCBtYWpvciB0eXBlIDUgb2YgbWFqb3IgdHlwZSA1LCAgICAgICAgICAgICBD b09MLCBtYWpvciB0eXBlIDQgb2YgDQptYWpvciB0eXBlIDUNCg0KDQoNCi0tDQpQZXRlciB2YW4g ZGVyIFN0b2sNCnZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCm1haWx0bzogY29uc3VsdGFuY3lAdmFu ZGVyc3Rvay5vcmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Thu Nov 19 06:55:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616661B2AEA for ; Thu, 19 Nov 2015 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TeJMF4tvuZy for ; Thu, 19 Nov 2015 06:55:03 -0800 (PST) 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 8E4081B2AFE for ; Thu, 19 Nov 2015 06:55:03 -0800 (PST) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 067A717214A; Thu, 19 Nov 2015 15:55:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 551-x_Y5Hf-0; Thu, 19 Nov 2015 15:55:00 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 08D4E17213D; Thu, 19 Nov 2015 15:54:58 +0100 (CET) Message-ID: <564DE2C1.50205@tzi.org> Date: Thu, 19 Nov 2015 15:54:57 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michel Veillette References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core , "lhotka@nic.cz" Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:55:09 -0000 Hi Michel, I'm not Peter, but: { "hat": "chair", "message": " We get to do COMI in CoRE (we hope -- the charter is still in process) because we have promised to work closely with the relevant network management groups. This means we'll need good reasons to deviate from what NETMOD etc. already have agreed to do. "} So I think that Peter's reminder to stay close to draft-ietf-netmod-yang-json -- unless we do need to deviate -- is quite germane. (If I were designing this from scratch, I would ask myself whether we shouldn't stay closer to the schemaless roots of JSON, e.g. by exposing the exponent in the representation data and not just in the YANG schema. But that is a discussion that maybe should be had in NETMOD, if at all.) I think the specific observation about decimal64 is that it is based on signed integers as the mantissae, so we need to allow negative numbers in CBOR as well as unsigned ones. To contrast this to a place where we may want to deviate, doing "bits" as an (unsigned) integer sounds right (at least until we need more than 64 of them in one "bits" item). This runs into the same numbering issues we have with the intra-module names, though. Gr眉脽e, Carsten PS.: Typo: Leafs of type binary MUST be encoded using a CBOR byte string data item (major type 0). (CBOR byte strings are major type 2.) From nobody Thu Nov 19 07:28:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5271B2B84 for ; Thu, 19 Nov 2015 07:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cweRz8qX1fe9 for ; Thu, 19 Nov 2015 07:27:53 -0800 (PST) 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 119301B2B75 for ; Thu, 19 Nov 2015 07:27:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ACBC91483; Thu, 19 Nov 2015 16:27:38 +0100 (CET) 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 uniHFXlpFkrX; Thu, 19 Nov 2015 16:27:37 +0100 (CET) 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, 19 Nov 2015 16:27:37 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAFF92006D; Thu, 19 Nov 2015 16:27:37 +0100 (CET) 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 4v_2a6Y39QaO; Thu, 19 Nov 2015 16:27:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58EDE20069; Thu, 19 Nov 2015 16:27:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 70C7038E35BF; Thu, 19 Nov 2015 16:27:35 +0100 (CET) Date: Thu, 19 Nov 2015 16:27:34 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20151119152734.GA3518@elstar.local> Mail-Followup-To: Carsten Bormann , Michel Veillette , Core , "lhotka@nic.cz" References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> <564DE2C1.50205@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <564DE2C1.50205@tzi.org> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lhotka@nic.cz" , Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2015 15:28:00 -0000 On Thu, Nov 19, 2015 at 03:54:57PM +0100, Carsten Bormann wrote: > > So I think that Peter's reminder to stay close to > draft-ietf-netmod-yang-json -- unless we do need to deviate -- is quite > germane. > I do not understand what "stay close to draft-ietf-netmod-yang-json" means. I think this requires an explanation. To give you an example: draft-ietf-netmod-yang-json is following I-JSON rules and one of them says that I-JSON numbers are limited in precision. As a consequence, 64-bit numbers are I-JSON encoded as strings for I-JSON compliance. I think CBOR does not require this since it does not have this particular restriction. So do we now continue to do this even though CBOR does not suffer from I-JSON limitations? I think my preference would be a clean mapping YANG to CBOR and not a mapping YANG to I-JSON to CBOR that carries I-JSON restrictions over to CBOR. The simple reason is that the longer the transformation chain, the more arcane rules you accumulate. But then the CBOR spec has already JSON to CBOR translation rules so YANG to I-JSON to CBOR is already defined somehow. Someone needs to compile a list of cases where YANG to CBOR would be different from YANG to JSON to CBOR before we can take an informed decision. /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 Nov 19 07:36:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120B11B2BA2 for ; Thu, 19 Nov 2015 07:36:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: 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-rvyDxNdFW8 for ; Thu, 19 Nov 2015 07:36:08 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4321B1B2B9A for ; Thu, 19 Nov 2015 07:35:42 -0800 (PST) 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.325.17; Thu, 19 Nov 2015 15:35:40 +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.0325.019; Thu, 19 Nov 2015 15:35:41 +0000 From: Michel Veillette To: Carsten Bormann Thread-Topic: [core] YANG to CBOR mapping Thread-Index: AQHRIrFRDohJFilcHkWMJpxQ90rIt56jTpSAgAAgjICAAAlmEA== Date: Thu, 19 Nov 2015 15:35:40 +0000 Message-ID: References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> <564DE2C1.50205@tzi.org> In-Reply-To: <564DE2C1.50205@tzi.org> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [24.225.215.88] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 5:QvIlUqvm4yiHicEP0KfMzCh5VZmVdD7+dr4WD4zn5fNPedMG4iAHiHPGlooRGEv44FtQN3gsPpHZYu/m+SaokNYFfFuUcHCIcmjK82LErVP6lKquGCdfs/Mi4YK9f7AcPJzBId2Ev1Pl5ORb1nl54g==; 24:wEVafnZJPUB9ZSWj7nQm7+HZQdQs/1ai2hDRlCTEJ69K03PuZqu1QQtGfR53+gmKBC5C8PQHOXQkbPHqlHW5Z1hw9OWpPlOLKp/FvJaV1x8=; 20:OtSf3j92RF0D7TWXpx+2LcRFrs3kub8wNBMXsx2fvhoJtfmKnZkrwgprBIF2bg3UKWxgyTCtthRe0tRf7UFePA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1762; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1762; x-forefront-prvs: 07658B8EA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(51444003)(13464003)(106356001)(97736004)(189998001)(105586002)(106116001)(99286002)(40100003)(19580395003)(5007970100001)(66066001)(86362001)(110136002)(81156007)(5004730100002)(5001960100002)(19580405001)(5002640100001)(586003)(122556002)(5003600100002)(10400500002)(5008740100001)(74316001)(87936001)(2900100001)(77096005)(102836003)(2950100001)(50986999)(76576001)(54356999)(76176999)(6116002)(33656002)(101416001)(3846002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1: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: 19 Nov 2015 15:35:40.7031 (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 , "lhotka@nic.cz" Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:36:20 -0000 SGkgQ2Fyc29uDQoNCkkgYWxyZWFkeSBzZW50IGFuIGVtYWlsIGFib3V0IHRoZSByZWFzb25zIHdo eSB3ZSBuZWVkIHRvIGRlZmluZSBhIGRpcmVjdCBtYXBwaW5nIChZQU5HIC0+IENCT1IpIGluc3Rl YWQgb2YgYSB0d28gc3RlcCBtYXBwaW5nIChZQU5HIC0+IEpTT04gLT4gQ0JPUikuIEkgaG9wZSB0 aGUgcmVhc29ucyBwcm92aWRlZCBhcmUgc2F0aXNmYWN0b3J5IHRvIHlvdS4NCg0KSXQncyBpbXBv cnRhbnQgdG8gbm90ZSBhbmQgcmVhbGl6ZSB0aGF0IHRoZSBhY3R1YWwgQ29NSSBkcmFmdCBhbHJl YWR5IGRvbid0IGNvbXBseSB3aXRoIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctanNvbiAoZS5nLiBs aXN0IG1hcHBpbmcpDQpUaGUgaW1wbGVtZW50IG9mIGJpdHMgdXNpbmcgYSBDQk9SIGJ5dGUgc3Ry aW5nIHdvbuKAmXQgYWxzbyBiZSBhbGlnbmVkIHdpdGggZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1q c29uDQpEZWZpbmluZyBhIHR3byBzdGVwIG1hcHBpbmcgKFlBTkcgLT4gSlNPTiAtPiBDQk9SKSBt YWtlIHRoaW5ncyBtb3JlIGNvbXBsZXggYW5kIG1pZ2h0IG5vdCBwcm9kdWNlIHRoZSBtb3N0IGVm ZmljaWVudCBlbmNvZGluZy4NCg0KVGhpcyBkb2Vzbid0IG1lYW5zIHdlIGRlc2lnbiB0aGlzIGZy b20gc3RhcmNoLg0KVGhlIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctanNvbiBkcmFmdCBpcyB1c2Vk IGFzIGEgdGVtcGxhdGUgdG8gZGVmaW5lZCB0aGUgKFlBTkcgLT4gQ0JPUikgbWFwcGluZy4NCg0K VGhhbmtzIGZvciB5b3VyIGNvbW1lbnQgYWJvdXQgZGVjaW1hbDY0IGFuZCB0aGUgdHlwby4NCg0K UmVncmFkcw0KDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENh cnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNhYm9AdHppLm9yZ10gDQpTZW50OiBOb3ZlbWJlci0xOS0x NSA5OjU1IEFNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlh bnRpbmMuY29tPg0KQ2M6IGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnOyBDb3JlIDxjb3JlQGll dGYub3JnPjsgbGhvdGthQG5pYy5jeg0KU3ViamVjdDogUmU6IFtjb3JlXSBZQU5HIHRvIENCT1Ig bWFwcGluZw0KDQpIaSBNaWNoZWwsDQoNCkknbSBub3QgUGV0ZXIsIGJ1dDoNCg0KeyAiaGF0Ijog ImNoYWlyIiwgIm1lc3NhZ2UiOiAiDQpXZSBnZXQgdG8gZG8gQ09NSSBpbiBDb1JFICh3ZSBob3Bl IC0tIHRoZSBjaGFydGVyIGlzIHN0aWxsIGluIHByb2Nlc3MpIGJlY2F1c2Ugd2UgaGF2ZSBwcm9t aXNlZCB0byB3b3JrIGNsb3NlbHkgd2l0aCB0aGUgcmVsZXZhbnQgbmV0d29yayBtYW5hZ2VtZW50 IGdyb3Vwcy4gIFRoaXMgbWVhbnMgd2UnbGwgbmVlZCBnb29kIHJlYXNvbnMgdG8gZGV2aWF0ZSBm cm9tIHdoYXQgTkVUTU9EIGV0Yy4gYWxyZWFkeSBoYXZlIGFncmVlZCB0byBkby4NCiJ9DQoNClNv IEkgdGhpbmsgdGhhdCBQZXRlcidzIHJlbWluZGVyIHRvIHN0YXkgY2xvc2UgdG8gZHJhZnQtaWV0 Zi1uZXRtb2QteWFuZy1qc29uIC0tIHVubGVzcyB3ZSBkbyBuZWVkIHRvIGRldmlhdGUgLS0gaXMg cXVpdGUgZ2VybWFuZS4NCg0KKElmIEkgd2VyZSBkZXNpZ25pbmcgdGhpcyBmcm9tIHNjcmF0Y2gs IEkgd291bGQgYXNrIG15c2VsZiB3aGV0aGVyIHdlIHNob3VsZG4ndCBzdGF5IGNsb3NlciB0byB0 aGUgc2NoZW1hbGVzcyByb290cyBvZiBKU09OLCBlLmcuIGJ5IGV4cG9zaW5nIHRoZSBleHBvbmVu dCBpbiB0aGUgcmVwcmVzZW50YXRpb24gZGF0YSBhbmQgbm90IGp1c3QgaW4gdGhlIFlBTkcgc2No ZW1hLg0KIEJ1dCB0aGF0IGlzIGEgZGlzY3Vzc2lvbiB0aGF0IG1heWJlIHNob3VsZCBiZSBoYWQg aW4gTkVUTU9ELCBpZiBhdCBhbGwuKQ0KDQpJIHRoaW5rIHRoZSBzcGVjaWZpYyBvYnNlcnZhdGlv biBhYm91dCBkZWNpbWFsNjQgaXMgdGhhdCBpdCBpcyBiYXNlZCBvbiBzaWduZWQgaW50ZWdlcnMg YXMgdGhlIG1hbnRpc3NhZSwgc28gd2UgbmVlZCB0byBhbGxvdyBuZWdhdGl2ZSBudW1iZXJzIGlu IENCT1IgYXMgd2VsbCBhcyB1bnNpZ25lZCBvbmVzLg0KDQpUbyBjb250cmFzdCB0aGlzIHRvIGEg cGxhY2Ugd2hlcmUgd2UgbWF5IHdhbnQgdG8gZGV2aWF0ZSwgZG9pbmcgImJpdHMiDQphcyBhbiAo dW5zaWduZWQpIGludGVnZXIgc291bmRzIHJpZ2h0IChhdCBsZWFzdCB1bnRpbCB3ZSBuZWVkIG1v cmUgdGhhbg0KNjQgb2YgdGhlbSBpbiBvbmUgImJpdHMiIGl0ZW0pLiAgVGhpcyBydW5zIGludG8g dGhlIHNhbWUgbnVtYmVyaW5nIGlzc3VlcyB3ZSBoYXZlIHdpdGggdGhlIGludHJhLW1vZHVsZSBu YW1lcywgdGhvdWdoLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNClBTLjogVHlwbzoNCiAgIExlYWZz IG9mIHR5cGUgYmluYXJ5IE1VU1QgYmUgZW5jb2RlZCB1c2luZyBhIENCT1IgYnl0ZSBzdHJpbmcg ZGF0YQ0KICAgaXRlbSAobWFqb3IgdHlwZSAwKS4NCihDQk9SIGJ5dGUgc3RyaW5ncyBhcmUgbWFq b3IgdHlwZSAyLikNCg== From nobody Thu Nov 19 08:28:55 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528CA1B2C5E for ; Thu, 19 Nov 2015 08:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mm3hjtMu5rG for ; Thu, 19 Nov 2015 08:28:47 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96C31A6FE0 for ; Thu, 19 Nov 2015 08:19:50 -0800 (PST) Received: by lbbcs9 with SMTP id cs9so46553384lbb.1 for ; Thu, 19 Nov 2015 08:19:49 -0800 (PST) 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:content-type; bh=Fo45V+r22sEwlq8OjIGDbA3vIGtioMhFL0bbaX4uAoI=; b=x+4ALNErpHsr2Gm7KJipN0pZ+y8s9b3EC9sf2dcYNht17oIz5hTiiN2YxqXFRcwgtN qmwkSTxjxhLUQQbQwUqWegjUwudvYhzPu9ZAz0k3JXsQpW6UdShxRtOfgfPedTzEEYaX bpufEJm2JuAc65H/5Ssa/V8NsAH6NxRzVxY9f88Qse3s8FOHBGL/DPzcezCh7SalEe5e MGOX9d3abLa5rG9fiN9biwhUOAFgBW0Yb0fM0qVpWLjmb3b1LQF7C9cg0M1InzS92CsZ 6IxQaqonrTwXn99IhSLaeToCl3uroMsFSAPmX5nNciuRd7MJz9t+ycSlB61YqRBXpnFm rc/w== 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:content-type; bh=Fo45V+r22sEwlq8OjIGDbA3vIGtioMhFL0bbaX4uAoI=; b=hQMGkANCp2qelpsupggOaOa+YqWX4o5ySibqzw8MYLQJA1nWz0vjz1hFx9wFANjO4M 0cyBjPhy09CsZflv2IpAAPTbCTYEu9ZOnh50MR21UVxQP5m4nrz9zA8O0pi0c79stIZz rybna4JiWLlj8iiQD6lCTOrfv2OfENrHXjSchMhViSlKvEryvMtTmBAoP/OGT14wpoz1 K+8TKdwFhw49m4hePHlmi482F1HzFsM5/M5E+HVO+Bcik2gORJ5jZmHx2xevSFt04yS1 HvjdXa/Os7yiMhmfnoFsp+4JOnuNlfHf4V894DKxTPf330xuGF8dhxJ5+v/Qi/hqoWBE tYxQ== X-Gm-Message-State: ALoCoQkrqfqD0bLifoEuOmLuOjcLvWPrNEfrjTSm4eC364pmAUAiHusVtokKAnOgHURdEIlfHnVW MIME-Version: 1.0 X-Received: by 10.112.140.197 with SMTP id ri5mr3705942lbb.65.1447949988769; Thu, 19 Nov 2015 08:19:48 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 19 Nov 2015 08:19:48 -0800 (PST) In-Reply-To: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> Date: Thu, 19 Nov 2015 08:19:48 -0800 Message-ID: From: Andy Bierman To: Somaraju Abhinav Content-Type: multipart/alternative; boundary=001a11c25b46bbccc00524e720b1 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:28:53 -0000 --001a11c25b46bbccc00524e720b1 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 19, 2015 at 2:06 AM, Somaraju Abhinav < abhinav.somaraju@tridonic.com> wrote: > Hi Andy, > please see inline for comments. > ------------------------------ > *From:* Andy Bierman [andy@yumaworks.com] > *Sent:* Wednesday, November 18, 2015 5:32 PM > *To:* Somaraju Abhinav > *Cc:* consultancy@vanderstok.org; Core > *Subject:* Re: [core] CoMI Cool draft splits > > > > On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav < > abhinav.somaraju@tridonic.com> wrote: > >> Hi Peter, >> I like your proposal of starting with the four drafts. Just a few comments >> >> - Before working through iv) function set, I think it makes a little bit >> of time working out what use cases we want to support. In particular, I >> think we should decide if we are only going to address Netconf/Restconf >> support or if we expect to support Yang application layer module >> management. In my opinion, in constrained networks we will not support two >> management protocols one for networking and one for application layer. >> Therefore, we should support both in the function set. >> >> > We don't know this term "YANG application layer module management" in the > NETMOD WG. > The semantics of the YANG module can be anything. The same language is > used for devices > and controllers, as well as application and server code generation by many > tools. > [AS] Agreed. But we understanding this explains what function set we want > to support. One example was the argument to include RPC/operations. I think > CoMI currently does not support RPCs because the need to do so was not > clear from a network management point of view. However, for applications, I > can provide clear reasons to do so. Same thing for "actions" from the Yang > 1.1 draft. > I think the term "constrained" is not widely agreed upon in the IETF. Why not just use RESTCONF and not bother with CoMI? At some point, the value of re-inventing everything becomes unclear. > >> - Access control. I think for iv) function set, we should also think >> about how access control is going to work while we look at the function >> set. I don't know if this is a separate draft in a different WG (e.g. ACE). >> But from the perspective of being able to use a device management protocol, >> unless we also get interoperability for access control/security mechanisms, >> the drafts will not be usable in the field. >> > > > Would this be a replacement for NACM, which is how authorization is handled > for YANG data. > [AS] Yes. I think CoMI/CoOL should recommend something similar to NACM. > Whether it is based on NACM or something new that is coming from ACE/COSE > is up for discussion. This also relates to the previous point about use > cases. Will we also use the same access control methods also for > application layer CoAP resources? > > We plan to just use NACM to configure what a client is authorized to access wrt/ management data and operations. Again, how much value is there in reinventing stuff? E.g., CooL copies ietf-yang-library inline just to change a string to a number. Same thing with ietf-yang-patch. IMO the savings from using CBOR are good enough. If the data models and protocol operations are altered, then supporting CoMI is a separate development effort for every data model. This does not scale well. I prefer to use the same code but with more efficient plumbing down in the transport. > >> - Regarding Versions of YANG modules: I do not understand why we need >> consistent numbering when a module version gets upgraded. As Rodney already >> mentioned, we can not assume that new versions of a module are supersets of >> old versions. I think it is also important to keep using the automated >> numbering scheme as far as possible. So, my questions is the following: do >> we need data node IDs consistent across versions of YANG modules. >> >> > > YANG is just like SMIv2 wrt/ permanent identifiers. > [AS] I did not realise that all YANG modules MUST have permanent module > identifiers. Could you please point me to the right reference where I can > read about this? Anyways, the permanent identifiers need not be the same as > the identifiers that should be used withing the API to access the modules > themselves (i.e the identifiers used withing CoOL to access data). > Therefore, my questions still stays the same, do data node IDs need to be > the same across multiple versions of the same module. > Look at section 10 in RFC 6020. This describes what is allowed to change in a new revision of a module. Notice how "rename object" is not in the list? Sec. 10 is normative. YANG modules that do not follow these rules are invalid modules. Stable identifiers are useful because old clients can continue to work with new servers. YANG allows old data to be extended with optional nodes. A new set of identifiers per revision requires the clients to store all versions of each identifier in order to maintain backward compatibility with old servers. Andy > > Once an ID is assigned it is never removed. > The 'status' statement is used to manage lifecycle issues like obsolete > objects. > So you can assume revision N+1 is a superset of N (at least for the purpose > of object identification). > > When a module is updated in the server, we usually attempt to minimize the > change > such that existing client code will continue to work without an upgrade. > This is how YANG Hash works. If the Cool numbers are version-specific, > then > a client needs to store multiple sets of IDs to work with each version, > and also > needs to be updated anytime a server it manages is updated. > > > Abhinav >> > > Andy > > >> >> ________________________________________ >> From: core [core-bounces@ietf.org] on behalf of peter van der Stok [ >> stokcons@xs4all.nl] >> Sent: Wednesday, November 18, 2015 8:27 AM >> To: Andy Bierman >> Cc: Core >> Subject: Re: [core] CoMI Cool draft splits >> >> > >> > I think the YANG Hash draft should be separate from the protocol. >> > We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >> > >> >> I agree with Andy here. >> Although I sympathize with Rodney, that once the four drafts are >> reality, the WG should decide about adoption and a recombination of >> documents. >> >> Peter >> >> _______________________________________________ >> 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. >> > > ________________________________________________________ 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. > --001a11c25b46bbccc00524e720b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 19, 2015 at 2:06 AM, Somaraju Abhinav <= ;abhinav= .somaraju@tridonic.com> wrote:
Hi Andy,
please see inline for comments.
From: Andy Bierman [andy@yumaworks.com]
Sent: Wednesday, November 18, 2015 5:32 PM
To: Somaraju Abhinav
Cc: = consultancy@vanderstok.org; Core
Subject: Re: [core] CoMI Cool draft splits



On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhin= av <abhi= nav.somaraju@tridonic.com> wrote:
Hi Peter,
I like your proposal of starting with the four drafts. Just a few comments<= br>
- Before working through iv) function set, I think it makes a little bit of= time working out what use cases we want to support. In particular, I think= we should decide if we are only going to address Netconf/Restconf support = or if we expect to support Yang application layer module management. In my opinion, in constrained network= s we will not support two management protocols one for networking and one f= or application layer. Therefore, we should support both in the function set= .


We don't know this term "YANG application layer module manage= ment" in the NETMOD WG.
The semantics of the YANG module can be anything.=C2=A0 The same langu= age is used for devices
and controllers, as well as application and server code generation by = many tools.
[AS] Agreed. But we understanding this explains what function set we w= ant to support. One example was the argument to include RPC/operations. I t= hink CoMI currently does not support RPCs because the need to do so was not= clear from a network management point of view. However, for applications, I can provide clear reasons to d= o so. Same thing for "actions" from the Yang 1.1 draft.



I think the term "constrained" is= not widely agreed upon in the IETF.
Why not just use RESTCONF an= d not bother with CoMI?
At some point, the value of re-inventing = everything becomes unclear.


=C2=A0
- Access control. I think for iv) function set, we should also think about = how access control is going to work while we look at the function set. I do= n't know if this is a separate draft in a different WG (e.g. ACE). But = from the perspective of being able to use a device management protocol, unless we also get interoperability for = access control/security mechanisms, the drafts will not be usable in the fi= eld.


Would this be a replacement for NACM, which is how authorization is ha= ndled
for YANG data.
[AS] Yes. I think CoMI/CoOL should recommend something similar to NACM= . Whether it is based on NACM or something new that is coming from ACE/COSE= is up for discussion. This also relates to the previous point about use ca= ses. Will we also use the same access control methods also for application layer CoAP resources?


We plan to just use NACM to configure what a client is= authorized to access
wrt/ management data and operations.=C2=A0 = Again, how much value is there
in reinventing stuff?=C2=A0 E.g., = CooL copies ietf-yang-library inline just to change
a string to a= number. Same thing with ietf-yang-patch. IMO the savings from using CBOR
are good enough.=C2=A0 If the data models and protocol operations = are altered, then supporting
CoMI is a separate development effor= t for every data model.=C2=A0 This does not scale well.
I prefer = to use the same code but with more efficient plumbing down in the transport= .



=C2=A0

- Regarding Versions of YANG modules: I do not understand why we need consi= stent numbering when a module version gets upgraded. As Rodney already ment= ioned, we can not assume that new versions of a module are supersets of old= versions. I think it is also important to keep using the automated numbering scheme as far as possible. So, my qu= estions is the following: do we need data node IDs consistent across versio= ns of YANG modules.



YANG is just like SMIv2 wrt/ permanent identifiers.
[AS] I did not realise that all YANG modules MUST have permanent modul= e identifiers. Could you please point me to the right reference where I can= read about this? Anyways, the permanent identifiers need not be the same a= s the identifiers that should be used withing the API to access the modules themselves (i.e the identifiers= used withing CoOL to access data). Therefore, my questions still stays the= same, do data node IDs need to be the same across multiple versions of the= same module.



Look at section 10 i= n RFC 6020.
This describes what is allowed to change in a new rev= ision of a module.
Notice how "rename object" is not in= the list?=C2=A0 Sec. 10 is normative.
YANG modules that do not f= ollow these rules are invalid modules.

Stable iden= tifiers are useful because old clients can continue to
work with = new servers.=C2=A0 YANG allows old data to be extended with
optio= nal nodes.=C2=A0 A new set of identifiers per revision requires
t= he clients to store all versions of each identifier in order to
m= aintain backward compatibility with old servers.

<= br>
Andy

=C2=A0

Once an ID is assigned it is never removed.
The 'status' statement is used to manage lifecycle issues like= obsolete objects.
So you can assume revision N+1 is a superset of N (at least for the pu= rpose
of object identification).

When a module is updated in the server, we usually attempt to minimize= the change
such that existing client code will continue to work without an upgrad= e.
This is how YANG Hash works.=C2=A0 If the Cool numbers are version-spe= cific, then
a client needs to store multiple sets of IDs to work with each version= , and also
needs to be updated anytime a server it manages is updated.


Abhinav

Andy
=C2=A0

________________________________________
From: core [core= -bounces@ietf.org] on behalf of peter van der Stok [stokcons@xs4all.nl]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

>
> I think the YANG Hash draft should be separate from the protocol.
> We want to use it with RESTCONF, as well as the YANG/CBOR encoding. >

I agree with Andy here.
Although I sympathize with Rodney, that once the four drafts are
reality, the WG should decide about adoption and a recombination of
documents.

Peter

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der 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.

________________________________________________________ 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 immediately notify the sender and= delete the e-mail and attached documents. Please note that neither the sen= der 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.

--001a11c25b46bbccc00524e720b1-- From nobody Thu Nov 19 08:37:51 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E22D1B2C6A for ; Thu, 19 Nov 2015 08:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEkKBRsaRcH2 for ; Thu, 19 Nov 2015 08:37:48 -0800 (PST) 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 8EEB01B2C48 for ; Thu, 19 Nov 2015 08:37:48 -0800 (PST) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 6B82B1720F3; Thu, 19 Nov 2015 17:37:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id yxYNXR-Uzlqd; Thu, 19 Nov 2015 17:37:46 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 55EFD1720E7; Thu, 19 Nov 2015 17:37:45 +0100 (CET) Message-ID: <564DFAD7.1000800@tzi.org> Date: Thu, 19 Nov 2015 17:37:43 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Andy Bierman References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> 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] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:37:49 -0000 Andy Bierman wrote: > I think the term "constrained" is not widely agreed upon in the IETF. No. But we are using it in the sense of RFC 7228 here. Gr眉脽e, Carsten From nobody Thu Nov 19 09:09:20 2015 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 028D91A0178; Thu, 19 Nov 2015 09:09:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151119170916.4931.10171.idtracker@ietfa.amsl.com> Date: Thu, 19 Nov 2015 09:09:16 -0800 Archived-At: Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-tcp-tls-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:09:16 -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 Working Group 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-01.txt Pages : 12 Date : 2015-11-19 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 19 09:12:33 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DAB1B2CFF for ; Thu, 19 Nov 2015 09:12:28 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHMS1eYTQdOu for ; Thu, 19 Nov 2015 09:12:18 -0800 (PST) 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 D22B21B2CFA for ; Thu, 19 Nov 2015 09:12:16 -0800 (PST) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 5E565FB8D2; Thu, 19 Nov 2015 18:12:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id PpsfcdHaHgMt; Thu, 19 Nov 2015 18:12:13 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 7DCD6FB88B; Thu, 19 Nov 2015 18:12:13 +0100 (CET) Message-ID: <564E02EB.7060002@tzi.org> Date: Thu, 19 Nov 2015 18:12:11 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: core@ietf.org References: <20151119170916.4931.10171.idtracker@ietfa.amsl.com> In-Reply-To: <20151119170916.4931.10171.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-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 17:12:28 -0000 Sorry for the quick re-spin: We have been alerted to a remnant of the length-field discussion, which seems to be quite confusing to those who now want to implement the decision. So -01 just has the removal of that remnant: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-01 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 Working Group 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-01.txt > Pages : 12 > Date : 2015-11-19 > > 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-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-tcp-tls-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From nobody Thu Nov 19 11:43:14 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B3E1B3499 for ; Thu, 19 Nov 2015 11:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrDbXicx0A2u for ; Thu, 19 Nov 2015 11:43:10 -0800 (PST) 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 6DC411B349B for ; Thu, 19 Nov 2015 11:43:09 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-57-564e264ac7ab Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.68.17026.A462E465; Thu, 19 Nov 2015 20:43:07 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.29]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 20:43:06 +0100 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: "Isomaki Markus (Nokia-TECH/Espoo)" Thread-Topic: [core] SemML time series data representation? Thread-Index: AdEiHUZ1breKcyk1Qzq1U/mXRYRdgQA3NneA Date: Thu, 19 Nov 2015 19:43:05 +0000 Message-ID: <8309DD6A-FED6-4E3D-86E8-FDF842BC9458@ericsson.com> References: <1d3a2378c7df499e84f3edae6f5d1f96@NOKWDCFIEXCH02P.nnok.nokia.com> In-Reply-To: <1d3a2378c7df499e84f3edae6f5d1f96@NOKWDCFIEXCH02P.nnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <5D9C9BC58767A549BD60CD3261C9B268@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7t663ml+YwcmtzBbLLzxnsdj3dj2z xYFpE1gtPqz/wWhx/u8iNgdWj6377zJ5LFnyk8nj8vmPjB53b11i8vhy+TNbAGsUl01Kak5m WWqRvl0CV8b3/jVMBWs6GSs+7z/K1sD4opWxi5GDQ0LAROJzA38XIyeQKSZx4d56ti5GLg4h gcOMElcnrmYGSQgJLGaUOPLQBMRmE7CVeNK6jxXEFhFwkvi87jQzSAOzwD1Gifbb/9hBhgoL WEmcX5UBUWMtsbX9JxuEbSTxZdkisJksAqoSPe2fWUBsXgF7iUmHPjBB7PKV2LX3HTuIzSng J9H15xJYPSPQcd9PrQGrYRYQl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwphK0ksuv2ZCeQcZgFN ifW79CFarSVaXnazQNiKElO6H7JDnCAocXLmE5YJjOKzkGyYhdA9C0n3LCTds5B0L2BkXcUo WpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGKkHt/zW3cG4+rXjIUYBDkYlHl4DGb8wIdbEsuLK 3EOMEhzMSiK8nopAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwtTA9ChQTSE0tSs1NTC1KLYLJM HJxSDYw8H9hbEndw/mDKM+rZ06twudNqwr1fPkI+jRXauxYp7p+m/POkG8O26k//E+78DVjL 9FSqfAbbxfIY7n9r3FlEZfiCTqn/WyjtXc9yqZ3r9OZ3qqzRd9Ofle/b/mhKV9+qnQ1GFytC tkrmnSvnmCn4wIWDJ1tm4n1rpc+HVqaYSlX+tDrS66nEUpyRaKjFXFScCABCkHoU0AIAAA== Archived-At: Cc: core , "draft-jennings-core-senml@tools.ietf.org" , =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= Subject: Re: [core] SemML time series data representation? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:43:13 -0000 SGkgTWFya3VzLA0KDQpUaGUgY3VycmVudCBzeW50YXggYWxsb3dzIHlvdSB0byBoYXZlIG11bHRp cGxlIGJhc2VzIGFuZCBoZW5jZSB5b3UgY291bGQgZHJvcCB0aGUgbiBlbGVtZW50cyBpZiBuZWVk ZWQuIFNvbWV0aGluZyBsaWtlOg0KDQogIFt7ImJuIjogInVybjpkZXY6bWFjOjAwMjRiZWZmZmU4 MDRmZjEvdm9sdGFnZSIsDQogICAgImJ0IjogMTI3NjAyMDA3NiwNCiAgICAiYnUiOiAiQSIsDQog ICAgInZlciI6IDF9LA0KICAgWyB7ICJ1IjogIlYiLCAidiI6IDEyMC4xIH0gXSwNCiAgIHsiYm4i OiAidXJuOmRldjptYWM6MDAyNGJlZmZmZTgwNGZmMS9jdXJyZW50In0sDQogICBbDQogICAgIHsg InQiOiAtNSwgInYiOiAxLjIgfSwNCiAgICAgeyAidCI6IC00LCAidiI6IDEuMzAgfSwNCiAgICAg eyAidCI6IC0zLCAidiI6IDAuMTRlMSB9LA0KICAgICB7ICJ0IjogLTIsICJ2IjogMS41IH0sDQog ICAgIHsgInQiOiAtMSwgInYiOiAxLjYgfSwNCiAgICAgeyAidCI6IDAsICAidiI6IDEuNyB9IF0N CiAgXQ0KDQpCdXQgZm9yIHRoZSBmdXJ0aGVyIGNvbXByZXNzaW9uIHlvdSBzdWdnZXN0ZWQgKGp1 c3QgdmFsdWVzKSB0aGVyZSBpcyBubyBtZWNoYW5pc20uDQoNCg0KQ2hlZXJzLA0KQXJpDQoNCj4g T24gMTggTm92IDIwMTUsIGF0IDE4OjM3LCBJc29tYWtpIE1hcmt1cyAoTm9raWEtVEVDSC9Fc3Bv bykgPG1hcmt1cy5pc29tYWtpQG5va2lhLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+IEkn dmUgbm90IGZvbGxvd2VkIENPUkUgb3IgU2VuTUwgZGlzY3Vzc2lvbnMgZm9yIGEgd2hpbGUsIHNv IGFwb2xvZ2llcyBpZiB0aGlzIGEgRkFRLiBJIG5vdGljZWQgdGhlcmUgaXMgYSBkaXNjdXNzaW9u IGFib3V0IFNlbk1MIHN0cmVhbWluZyBhbmQgdGhhdCB0cmlnZ2VyZWQgYSBxdWVzdGlvbiByZWxh dGVkIHRvIGEgcHJvamVjdCBJJ20gd29ya2luZyBvbi4gQmFzaWNhbGx5IEkgd291bGQgbGlrZSB0 byBzZW5kIGEgbGFyZ2UgbnVtYmVyIG9mIHNlbnNvciByZWFkaW5ncyB0aGF0IGhhdmUgYmVlbiBt ZWFzdXJlZCB3aXRoIGEgY29uc3RhbnQgc2FtcGxlIHJhdGUuIFRoaXMgY291bGQgYmUgZXZlbiB0 ZW5zIG9mIHRob3VzYW5kcyBvZiBzYW1wbGVzIGF0IGEgdGltZS4gSW4gU2VuTUwsIGlzIHRoZXJl IGFueSByZWFzb25hYmxlIHdheSB0byByZXByZXNlbnQgdGhpcyB0eXBlIG9mIHRpbWUgc2VyaWVz IGluIGEgY29tcGFjdCBtYW5uZXI/IEluIHRoZSBkcmFmdCBJIHNlZSB0aGlzIGtpbmQgb2YgZXhh bXBsZToNCj4gDQo+ICAgW3siYm4iOiAidXJuOmRldjptYWM6MDAyNGJlZmZmZTgwNGZmMS8iLA0K PiAgICAgImJ0IjogMTI3NjAyMDA3NiwNCj4gICAgICJidSI6ICJBIiwNCj4gICAgICJ2ZXIiOiAx fSwNCj4gICAgWyB7ICJuIjogInZvbHRhZ2UiLCAidSI6ICJWIiwgInYiOiAxMjAuMSB9LA0KPiAg ICAgIHsgIm4iOiAiY3VycmVudCIsICJ0IjogLTUsICJ2IjogMS4yIH0sDQo+ICAgICAgeyAibiI6 ICJjdXJyZW50IiwgInQiOiAtNCwgInYiOiAxLjMwIH0sDQo+ICAgICAgeyAibiI6ICJjdXJyZW50 IiwgInQiOiAtMywgInYiOiAwLjE0ZTEgfSwNCj4gICAgICB7ICJuIjogImN1cnJlbnQiLCAidCI6 IC0yLCAidiI6IDEuNSB9LA0KPiAgICAgIHsgIm4iOiAiY3VycmVudCIsICJ0IjogLTEsICJ2Ijog MS42IH0sDQo+ICAgICAgeyAibiI6ICJjdXJyZW50IiwgInQiOiAwLCAgInYiOiAxLjcgfSBdDQo+ ICAgXQ0KPiANCj4gVGhpcyBraW5kIG9mIHdvcmtzIGJ1dCBpdCB3b3VsZCBiZSBxdWl0ZSByZWR1 bmRhbnQgdG8gbGl0ZXJhbGx5IHNlbmQgICAibiI6ImN1cnJlbnQiLCJ0IjpOLCAidiI6ICAgdGVu IHRob3VzYW5kIHRpbWVzLiBUaGUgY3VycmVudCBmb3JtYXQgd2UgYXJlIHVzaW5nIGhhcyBhZGRp dGlvbmFsIG1ldGFkYXRhIHN1Y2ggYXMgc2FtcGxlIHJhdGUgKG9yIHNhbXBsZSBpbnRlcnZhbCks IGFuZCBhbHNvIHRoZSBtZWFzdXJlbWVudCB0eXBlIGFuZCB0aGUgbWVhc3VyZW1lbnQgdW5pdCBj YW4gYmUgZ2l2ZW4gb25seSBvbmNlLiBUaGlzIG1lYW5zIHdlIGNhbiBqdXN0IHNlbmQgYW4gYXJy YXkgb2YgYWN0dWFsIG1lYXN1cmVtZW50IHJlc3VsdHMgb2YgdGhlIHNhbWUgdHlwZSBhbmQgc2Ft cGxlIGludGVydmFsLCBlLmcuIFsxLjIsIDEuMzAsIDAuMTRlMSwgMS41LCAxLjYsIDEuN10sIGlu IGEgY29tcGFjdCBtYW5uZXIuDQo+IA0KPiBJcyB0aGlzIHBvc3NpYmxlIGluIFNlbk1MPyBXb3Vs ZCBzZWVtIGxpa2UgYSB1c2VmdWwgZmVhdHVyZSBmb3IgbWFueSBwdXJwb3NlcyB3aGVyZSBzZW5z b3JzIHJlcG9ydCBkYXRhIGluIGJhdGNoZXMuIA0KPiANCj4gTWFya3VzIA0KPiANCj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjb3JlIFttYWlsdG86Y29yZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIEN1bGxlbiBKZW5uaW5ncw0KPj4gU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAxOCwgMjAxNSA0OjE1IEFNDQo+PiBUbzogQ2hyaXN0aWFuIEFtc8O8 c3MgPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0Pg0KPj4gQ2M6IGRyYWZ0LWplbm5pbmdz LWNvcmUtc2VubWxAdG9vbHMuaWV0Zi5vcmc7IGNvcmUgPGNvcmVAaWV0Zi5vcmc+DQo+PiBTdWJq ZWN0OiBSZTogW2NvcmVdIFNlbk1MIEpTT04gc3ludGF4IGFuZCBjb2xsZWN0aW9uK3Nlbm1sK2pz b24NCj4+IA0KPj4gDQo+PiBSYW5kb20gdGhvdWdodHMgb24gYSAgZmV3IHN1YmplY3RzOg0KPj4g DQo+PiBJIGZlZWwgbGlrZSBTZW5NTCBpcyBnZXR0aW5nIHRvIGNvbXBsZXggYW5kIHdlIHNob3Vs ZCBhc2sgaWYgd2UgY2FuIHB1dCBpdCBvbiBhDQo+PiBkaWV0LiBQZXJoYXBzIHRoaXMgc3RyZWFt aW5nIGlzIGp1c3QgdG9vIG11Y2ggdG8gcHV0IGludG8gaXQuIEFuIGFsdGVybmF0aXZlIGlzIHRv DQo+PiBub3QgaGF2ZSBTZW5NTCBkbyBzdHJlYW1pbmcgYnV0IGFsbG93IGEgcHJvdG9jb2wgdXNp bmcgaXQgdG8gc3VwcG9ydA0KPj4gc3RlYW1pbmcgYnkgc2VuZGluZyBtYW55IFNlbk1MIG9iamVj dHMgd2l0aCB0aGUgY29udmVudGlvbiB0aGF0IGlzIGFueQ0KPj4gZ2l2ZW4gb2JqZWN0IGRpZCBu b3QgaGF2ZSBhIGJhc2UgdmFsdWUsIHRoZW4gdGhlIGJhc2UgdmFsdWVzIGZyb20gdGhlDQo+PiBw cmV2aW91cyBTRU5NTCBvYmplY3QgYXBwbGllZC4gSSdtIG5vdCBzdXJlIGlmIHRoaXMgaXMgYSBn b29kIGlkZWEgb3Igbm90IGJ1dA0KPj4gSSdtIGp1c3Qgc2F5aW5nIHRoYXQgaWYgdGhpbmdzIHN0 YXJ0IHRvIGdldCB0b28gY29tcGxpY2F0ZWQgdG8gZG8gc3RyZWFtaW5nDQo+PiBpbnNpZGUgU2Vu TUwsIHdlIGNhbiBwdW50IGl0IHVwIGEgbGF5ZXIuDQo+PiANCj4+IA0KPj4gQ29tcGxleGl0eSA6 DQo+PiANCj4+IEknbSBzdXJlIHNvbWVvbmUgd2lsbCB0aGluayBJIGFtIG51dHMgZm9yIHN1Z2dl c3RpbmcgdGhhdCBTZW5NTCBpcyBsb29raW5nDQo+PiB0b28gY29tcGxpY2F0ZWQgYnV0IGFzIGFu b3RoZXIgZXhhbXBsZSAuLi4gdGFrZSBJbmZsdXhEQiB3aGljaCBpcyBwcmV0dHkNCj4+IGdvb2Qg Zm9yIHN0dWZmIGxpa2UgdGhpcy4gSXZlIGJlZW4gdXNpbmcgaXQgZm9yIGEgY2xvdWQgREIgZm9y IHN0cmVhbWluZyBSVA0KPj4gbWVhc3VyZW1lbnRzLiBJdCBkZXByZWNhdGVkIEpTT04gYW5kIHJl cGxhY2VkIGl0IHdpdGggIkxpbmUgUHJvdG9jb2wiDQo+PiB3aGljaCBpcyBlZmZlY3RpdmVseSB0 aGUgc2Vuc29yIG5hbWUgZm9sbG93ZWQgYnkgc3BhY2Ugc2VwYXJhdGVkICBmb2xsb3dlZA0KPj4g YnkgdGhlIHZhbHVlIGZvbGxvd2VkIGJ5IENSTEYuIFRoYXQgcHJvZHVjZWQgbm90aWNlYWJsZSBp bXByb3ZlbWVudHMgaW4NCj4+IHJlYWwgZGVwbG95bWVudHMgb3ZlciBnZW5lcmFsIEpTT04uIEEg YmlnIHBhcnQgb2YgU2VuTUwgd2FzIHRvICpub3QqIGJlIGJlDQo+PiBnZW5lcmFsIEpTT04gYW5k IGJlIGEgdmVyeSByZXN0cmljdGVkIHN1YnNldCBvZiBKU09OIHN1Y2ggdGhhdCBpdCBjb3VsZA0K Pj4gYWNoaWV2ZSB0aGUgcGVyZm9ybWFuY2Ugb2Ygc29tZXRoaW5nIGxpa2UgIkxpbmUgUHJvdG9j b2wiIG9yIHByb3RvIGJ1ZnMgYW5kDQo+PiBzdGlsbCBoYXZlIHNvbWUgZXh0ZW5zaWJpbGl0eSBz dG9yeS4NCj4+IA0KPj4gU28gTGluZSBQcm90b2NvbCB3b3VsZCBzZW5kIHRoZSBleGFtcGxlIGZy b20gbGF0ZXIgaW4gdGhpcyBlbWFpbCBhcyBhIHNpbmdsZQ0KPj4gbGluZSB3aXRoDQo+PiANCj4+ IHVybjpkZXY6bWFjOjAwMjRiZWZmZmU4MDRmZjEvdm9sdGFnZSB1PVYgMTIwLjENCj4+IA0KPj4g DQo+PiANCj4+IE1ldGFEYXRhOg0KPj4gDQo+PiBUaGUgbW9yZSBJIHRoaW5rIGFib3V0IG1ldGFk YXRhIGFuZCBkYXRhIHRoZSBsZXNzIEkga25vdyB3aGljaCBpcyB3aGF0Lg0KPj4gQ29uc2lkZXIN Cj4+IA0KPj4gWyB7ImJuIjogInVybjpkZXY6bWFjOjAwMjRiZWZmZmU4MDRmZjEvIn0sDQo+PiAg ICBbIHsgIm4iOiAidm9sdGFnZSIsICJ0IjogMCwgInUiOiAiViIsICJ2IjogMTIwLjEgfSBdICBd DQo+PiANCj4+IFlvdSBjb3VsZCBhcmd1ZSB0aGUgb25seSB0aGluZyB0aGF0IGlzIG5vdCBtZXRh ZGF0YSBpcyAxMjAuMQ0KPj4gDQo+PiBJIHRoaW5rIHRoZSBnb2FsIG9mIFNlbk1MIGlzIHRvIGhh dmUgYSByZWNvcmQgdGhhdCBoYXMgYSBtaW5pbWFsIHNldCBvZiBpbmZvDQo+PiB0aGF0IGlzIG9m dGVuIG5lZWRlZCB0byBpbnRlcnByZXQgdGhlIGRhdGEgaW4gb25lIHJlY29yZC4gVGhlIGJhc2Ug bmFtZXMNCj4+IHdlcmUgYWRkZWQgbWVyZWx5IGFzIGNvbXByZXNzaW9uIHNjaGVtZSB0byByZWR1 Y2UgZHVwbGljYXRpb24gb2Ygc2FtZQ0KPj4gYml0cyBzZXZlcmFsIHRpbWVzLiBJJ20gbm90IHJl YWwgd291bmQgdXAgYWJvdXQgaXQgc29tZSBvZiBpdCBpcyBtZXRhIGRhdGEgb3INCj4+IG5vdC4N Cj4+IA0KPj4gDQo+PiANCj4+IFN0cmVhbWluZzoNCj4+IA0KPj4gV2hlbiBJIGZpcnN0IHJlYWQg dGhhdCBsaW5lIHRoYXQgc2FpZCB0aGUgbGF0ZXN0IFNlbk1MIGRyYWZ0ICJyZXF1aXJlcyBzdXBw b3J0DQo+PiBvZiBzdHJlYW1pbmciIEkgdGhvdWdodCB0aGF0IHdhcyB3cm9uZyBidXQgdGhlIG1v cmUgSSB0aG91Z2h0IGFib3V0IGl0LCB5ZXMsDQo+PiBJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IHNl cmlvdXMgcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2FsLiBJIHdhcyB0aGlua2luZw0K Pj4gYWJvdXQgc2Vuc29yIGRhdGEgYmVpbmcgc2VuZCBmcm9tIGEgc21hbGwgZGV2aWNlIHRvIGEg YmlnIGNsb3VkIGRldmljZSBhbmQNCj4+IHRoaXMgbWlnaHQgd29yayBPSyBidXQgaW4gdGhlIGNh c2Ugb2YgZGF0YSBnb2luZyB0byBhbm90aGVyIHNtYWxsIGRldmljZSwgdGhpcw0KPj4gaXMgYSBw cm9ibGVtLiBJdCBkb2VzIGhpZ2hsaWdodCB0aGUgcHJvYmxlbSBvZiBtYXggc2l6ZSBmb3IgYSBT ZW5NTCBkYXRhLg0KPj4gDQo+PiBQZXJoYXBzIHdlIG5lZWQgdHdvIGRpZmZlcmVudCBmb3JtYXRz IC0gYSBTZW5NTCBvYmplY3QgYW5kIGEgU2VuTUwNCj4+IHN0cmVhbS4gVGhhdCB3b3VsZCBhbGxv dyBwcm90b2NvbHMgdGhhdCB1c2VkIHRoaXMgdG8gYmUgY2xlYXIgYWJvdXQgaWYgdGhleQ0KPj4g dXNlZCBvbmUgb3IgdGhlIG90aGVyIG9yIGJvdGggYW5kIHdpdGggSFRUUCBvciBDb0FQLCB0aGUg bm9ybWFsDQo+PiBhcHByb2FjaGVzIGNvdWxkIGJlIHVzZWQgdG8gbmVnb3RpYXRlIHRoZW0uDQo+ PiANCj4+IA0KPj4gDQo+Pj4gT24gTm92IDE3LCAyMDE1LCBhdCAzOjQ0IFBNLCBDaHJpc3RpYW4g QW1zw7xzcw0KPj4gPGMuYW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0PiB3cm90ZToNCj4+PiAN Cj4+PiBIZWxsbyBNaWNoYWVsLA0KPj4+IGhlbGxvIFNlbk1MIGFuZCBjb3JlLWludGVyZmFjZXMg cGVvcGxlLA0KPj4+IA0KPj4+IEknZCBsaWtlIHRvIHBpY2sgdXAgdGhlIHRvcGljIG9mIHN0cmVh bWFibGUgU2VuTUwgZnJvbSB0aGUgY29udGV4dCBvZg0KPj4+IHRoZSBgU2VuTUwgSlNPTiBzeW50 YXhgIHN5bnRheCB0aHJlYWQgZnJvbSBiZWZvcmUgSUVURjk0Lg0KPj4+IA0KPj4+IFRvIHN1bW1h cml6ZSB3aGF0IEkga25vdyBvZiB0aGUgc3RhdGUgb2YgdGhpbmdzOg0KPj4+IA0KPj4+ICogSlNP TiBTZW5NTCBjYW4ndCBlbmZvcmNlIHRoYXQgdGhlIGJhc2Uge25hbWUsIHRpbWV9IGVudHJpZXMg cHJlY2VkZQ0KPj4+IHRoZSBlbnRyaWVzIGxpc3Qgd2hpbGUgc3RpbGwgYmVpbmcgSlNPTi4gVG8g cGFyc2UgYSBnZW5lcmljIFNlbk1MDQo+Pj4gbWVzc2FnZSwgaXQgaXMgdGh1cyByZXF1aXJlZCB0 byBrZWVwIHRoZSB3aG9sZSBtZXNzYWdlIGluIG1lbW9yeS4NCj4+PiANCj4+PiBBbiBhbHRlcm5h dGl2ZSBzeW50YXggaXMgcHJvcG9zZWQgW3tiYXNlIGRpY3R9LCBbZW50cmllc11dOyB0aGF0IGNh bg0KPj4+IGJlIGV4dGVuZGVkIHRvIGFsbG93IHJlcGV0aXRpb25zIHRoZXJlb2YgKHdpdGggaW5j cmVtZW50YWwgYmFzZQ0KPj4+IHZhbHVlcyksIG9yIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGJh c2UgYW5kIGVudHJ5IGRhdGEgY291bGQgYmUNCj4+PiBsaWZ0ZWQgZnVydGhlci4NCj4+PiANCj4+ PiBUaGlzIGFzc3VtZXMgdGhhdCB0aGUgImUiIHJlY29yZCBsaXN0IHRha2VzIGEgc3BlY2lhbCBy b2xlIGluIFNlbk1MDQo+Pj4gYnkgIGJlaW5nIHRoZSB3b3JraG9yc2UgbGlzdCBvZiBkYXRhLCB3 aGljaCBjb25mbGljdHMgd2l0aDoNCj4+PiANCj4+PiAqIENvUkUgaW50ZXJmYWNlcyBzZXJ2ZXMg Y29sbGVjdGlvbnMgYXMgYm90aCBkYXRhIGFuZCBtZXRhZGF0YSBpbiBhDQo+Pj4gdW5pZmllZCBT ZW5NTCBzdHJ1Y3R1cmUsIHdoZXJlIHJlc291cmNlIHN0YXRlcyBhcmUgZ2l2ZW4gaW4gdGhlDQo+ Pj4gY2xhc3NpY2FsICJlIiBhcnJheSwgYW5kIHRoZSBtZXRhZGF0YSBuZXh0IHRvIGl0IGluIGFu ICJsIiBhcnJheSBhcyBpbg0KPj4+IGFwcGxpY2F0aW9uL2xpbmstZm9ybWF0K2pzb24uDQo+Pj4g DQo+Pj4gQSBub3RhdGlvbiBmb3IgdHJlYXRpbmcgdGhlICJsIiBhcnJheSBhcyBhbiAiZSIgZWxl bWVudCB3YXMgcHJvcG9zZWQsDQo+Pj4gYnV0IGRpZCBub3QgcmVzb25hdGUgd2VsbCB3aXRoIE1p Y2hhZWwgKGZyb20gdGhlIENvUkUgaW50ZXJmYWNlIHNpZGUpOw0KPj4+IEknZCBsaWtlIHRvIHRh a2UgdXAgdGhlIGxpbmUgb2YgZGlzY3Vzc2lvbiBmcm9tIHRoZXJlOg0KPj4+IA0KPj4+IE9uIFR1 ZSwgT2N0IDIwLCAyMDE1IGF0IDEyOjUyOjE5UE0gLTA3MDAsIE1pY2hhZWwgS29zdGVyIHdyb3Rl Og0KPj4+PiBJdOKAmXMgbW9yZSB0aGFuIGEgc2ltcGxlIHZpc3VhbCByZWxhdGlvbnNoaXAuIEni gJltIHVzZWQgdG8gSlNPTiB0b29scw0KPj4+PiB0aGF0IGNyZWF0ZSBhbiBpbi1tZW1vcnkgZGF0 YSBzdHJ1Y3R1cmUgdGhhdCBjb25mb3JtcyB0byB0aGUgSlNPTg0KPj4+PiBzZXJpYWxpemF0aW9u LiBXaXRoIHRoZSDigJxvbGTigJ0gU2VuTUwgbW9kZWwsIHRoZSBlbGVtZW50cyBvZiB0aGUgb2Jq ZWN0DQo+Pj4+IGlkZW50aWZpZWQgYnkg4oCcYm7igJ0gYXJlIHJlbmRlcmVkIGFzIGFuIGFycmF5 IHdpdGhpbiB0aGUgZWxlbWVudA0KPj4+PiBpZGVudGlmaWVkIGJ5IOKAnGJu4oCdIGFuZCB0YWdn ZWQgYnkg4oCcZeKAnS4NCj4+Pj4gDQo+Pj4+IFRoZSBuZXcgY29uc3RydWN0IG1vcmUgdGhhbiBq dXN0IGVuYWJsZXMgc3RyZWFtaW5nLCBpdCBmb3JjZXMgc2VyaWFsDQo+Pj4+IGludGVycHJldGF0 aW9uLCBpLmUuIGl0ICpyZXF1aXJlcyogc3RyZWFtaW5nLg0KPj4+IA0KPj4+IFllcywgYW5kIHRo YXQncyB0aGUgdmVyeSBwb2ludC4gSWYgSSdtIHRvIHBhcnNlIFNlbk1MIG9uIGEgY29uc3RyYWlu ZWQNCj4+PiBkZXZpY2UsIGVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCB0aGUgc2VuZGVyIGNhbiB1c2Ug aXRzIGV4dGVuc2liaWxpdHkgdG8NCj4+PiBzZW5kIGFsb25nIGRhdGEgdGhhdCBpcyBub3QgZXhw ZWN0ZWQgYnkgdGhlIHJlY2VpdmVyLCB0aGF0IG1lYW5zIHRoYXQNCj4+PiBJIG5lZWQgdG8gYmUg cHJlcGFyZWQgdG8gc3RvcmUgd2hpY2hldmVyIGxlbmd0aCB0aGUgY29tcGxldGUgbWVzc2FnZQ0K Pj4gaGFzLg0KPj4+IA0KPj4+IEZvciBhbiBleGFtcGxlIG9mIGEgc2l0dWF0aW9uIHdoZW4gdGhp cyBjYW4gYmUgYW4gaXNzdWUsIHRha2UgYW4NCj4+PiB1cGRhdGUgdG8gYSBETVggKFJHQiBzcG90 cyBvciBvdGhlciBsaWdodCBpbnN0YWxsYXRpb25zKSBjb250cm9sbGVyLiBBDQo+Pj4gUFVUIHRv IGF0b21pY2FsbHkgdXBkYXRlIHRoZSBjb21wbGV0ZSBzY2VuZSBvZiBjb25uZWN0ZWQgZGV2aWNl cyBpbg0KPj4+IEpTT04gc2VyaWFsaXphdGlvbiBjYW4gZWFzaWx5IHRha2UgdXAgMTBrIHBsdXMg bmV0d29yayBvdmVyaGVhZCBpbg0KPj4+IG5ldHdvcmsgYnVmZmVyIHNwYWNlIGV2ZW4gd2l0aG91 dCBhbnkgYWRkaXRpb25hbCBtZXRhZGF0YSBmcm9tIFNlbk1MDQo+Pj4gZXh0ZW5zaW9ucywgYnV0 IChpZiByZWFkIGluIGEgc2VyaWFsaXphYmxlIHdheSkgaW1wbGVtZW50YXRpb25zIGNvdWxkDQo+ Pj4gZ2V0IGF3YXkgd2l0aCBhIHNpbmdsZS1NVFUtYnVmZmVyIG5ldHdvcmsgaW1wbGVtZW50YXRp b24gcGx1cyAxayBmb3INCj4+PiBkb3VibGUtYnVmZmVyZWQgc3RhdGUuDQo+Pj4gDQo+Pj4gQW5v dGhlciBleGFtcGxlIChmcm9tIG15IGV2ZXJ5ZGF5IENvQVAgY29tbXVuaWNhdGlvbiwgYnV0IG5v dA0KPj4+IGludm9sdmluZyBlbWJlZGRlZCBwYXJzaW5nKSBhcmUgaGlzdG9yeSByZWFkb3V0cyBv ZiBzZW5zb3IgdmFsdWVzLA0KPj4+IHdoaWNoIGNhbiBleGNlZWQgMTAwa0IgZm9yIGRldmljZXMg d2l0aCBpbnRlcm1pdHRlbnQgbmV0d29yaw0KPj4gY29ubmVjdGl2aXR5Lg0KPj4+IA0KPj4+PiBX b3VsZCBpdCBtYWtlIHNlbnNlIHRvIGNyZWF0ZSBhIG5ldyBjb250ZW50LWZvcm1hdCB0aGF0IG9w dGltaXplcyBmb3INCj4+Pj4gc3RyZWFtaW5nIHByb2Nlc3Npbmc/DQo+Pj4gDQo+Pj4gVGhpcyBp cyBub3QgYWJvdXQgc3RyZWFtaW5nIEJpZyBEYXRhIGFyb3VuZCB0byB0aGUgcG9pbnQgd2hlcmUg YmlnDQo+Pj4gZGV2aWNlcyBuZWVkIHRvIGdvIGludG8gInN0cmVhbWluZyBtb2RlIiAodGhvdWdo IGl0J3MgdXNlZnVsIHRoZXJlDQo+Pj4gdG9vKSwgdGhpcyBpcyBhYm91dCAobm90IHRoZSBtb3N0 IGNvbW1vbiwgYnV0IHN0aWxsIHJlbGF0aXZlbHkpIG5vcm1hbA0KPj4+IHNpdHVhdGlvbnMgYW5k IG5vdCByZXR1cm5pbmcgNC4xMyBmcm9tIHNtYWxsIGRldmljZXMgYW55IHRpbWUgc29tZW9uZQ0K Pj4+IGRvZXNuJ3QgY2h1bmsgdXAgaGlzIHJlcXVlc3QgdG8gc21hbGwgbXVsdGlwbGVzIG9mIHRo ZSBNVFUuDQo+Pj4gDQo+Pj4gSSBkb24ndCBsaWtlIHRvIGV4YWdnZXJhdGUsIHNvIHBsZWFzZSB0 YWtlIHRoaXMgd2l0aCBhIGdyYWluIG9mIHNhbHQNCj4+PiBhbmQgYXdhcmUgdGhhdCB0aGlzIGlz IHdyaXR0ZW4gaW4gdGhlIGhlYXQgb2YgdGhlIGFyZ3VtZW50OiBJZiB3ZQ0KPj4+IGRvbid0IGZp bmQgYW4gYWdyZWVhYmxlIHNlcmlhbGl6YXRpb24gdGhhdCBjYW4gYmUgcHJvY2Vzc2VkIGluIGEN Cj4+PiBzdHJlYW1pbmcgZmFzaGlvbiwgd2UgbWlnaHQgcmlnaHQgYXMgd2VsbCBwdXQgYSBoYXJk IGxpbWl0IHRvIHRoZQ0KPj4+IG1heGltdW0gc2l6ZSBvZiBhIFNlbk1MIHJlcHJlc2VudGF0aW9u LCB0aGF0IGFyZSBhIHJlcXVpcmVkIG1pbmltdW0NCj4+PiBmb3IgU2VuTUwgaW1wbGVtZW50b3Jz IHRvIHN1cHBvcnQuIFdoYXQgd291bGQgdGhhdCBiZSwgNGs/IDE2az8NCj4+PiANCj4+Pj4+IElu IG15IG9waW5pb24sIGl0IHJhaXNlcyB0aGUgcXVlc3Rpb24gb2YgaG93IGdlbmVyaWMgU2VuTUwg c2hvdWxkDQo+Pj4+PiBhdHRlbXB0IHRvIGJlLiBNeSBwZXJzb25hbCB2aWV3IG9mIGl0IGlzIHRo YXQgU2VuTUwgaXMgYSB3YXkgb2YNCj4+Pj4+IGVuY2Fwc3VsYXRpbmcgc2V2ZXJhbCByZXNvdXJj ZSByZXByZXNlbnRhdGlvbnMgKGJlIHRoZXkgb2YgZGlmZmVyZW50DQo+Pj4+PiBwb2ludHMgaW4g dGltZSBvciBkaWZmZXJlbnQgcmVzb3VyY2UpIGluIGEgc2luZ2xlIG1lc3NhZ2UuIFdpdGggdGhh dA0KPj4+Pj4gaW4gbWluZCwgbWF5YmUgdGhlIGZvbGxvd2luZyB3b3VsZCB3b3JrIGZvciB5b3Ug KHJlcGhyYXNpbmcgeW91cg0KPj4+Pj4gZXhhbXBsZSBpbnRvIHNlbm1sLTAyIHN5bnRheCwgd2l0 aCBjb21tZW50cyk6DQo+Pj4+IA0KPj4+PiBTZW5NTCBpcyBhbHJlYWR5IGJlaW5nIHVzZWQgdG8g cmVwcmVzZW50IHNpbXBsZSBjb2xsZWN0aW9ucyBpbiBDb1JFDQo+Pj4+IEludGVyZmFjZXMsIE9N QSBMV00yTSwgYW5kIE9JQy4gV2hldGhlciB0byBoYXZlIGl0IGJlIGV4dGVuc2libGUgYW5kDQo+ Pj4+IGV2b2x2YWJsZSBvciBub3QgaXMgY2VydGFpbmx5IGEgdHJhZGVvZmYgYWdhaW5zdCBjb21w bGV4aXR5IGFuZA0KPj4+PiBzdHJlYW0gcHJvY2Vzc2luZyBhYmlsaXR5LiBJIHdvdWxkIGxlYW4g dG93YXJkIGV2b2x2YWJpbGl0eS4NCj4+PiANCj4+PiBDb25jZXJuaW5nIGV2b2x2YWJpbGl0eToN Cj4+PiANCj4+PiBUaGF0IHNob3VsZG4ndCBiZSBhIHNob3cgc3RvcHBlcjogZXh0ZW5zaW9ucyBj YW4gc3RpbGwgZ28gYm90aCBpbiB0aGUNCj4+PiBiYXNlIGRpY3Rpb25hcnkgYW5kIGluIHRoZSBl dmVudHM7IGl0J3MganVzdCB0aGV5IHdvdWxkbid0IHByb2ZpdCBmcm9tDQo+Pj4gdGhlIGd1YXJh bnRlZWQgc2VxdWVuY2UuDQo+Pj4gDQo+Pj4gQW4gYXBwcm9hY2ggSSBkb24ndCBsaWtlIGluIGl0 cyBjdXJyZW50IGZvcm0gYnV0IHRoYXQgY291bGQgcG9pbnQgdGhlDQo+Pj4gZGlyZWN0aW9uIGZv ciBzb21ldGhpbmcgbW9yZSBlbGVnYW50IGlzIHRvIGluZGljYXRlIHRoZSAia2V5IiBvZg0KPj4+ IHN1YnNlcXVlbnQgbGlzdHMgaW4gdGhlIGJhc2UgZGljdGlvbmFyeTsgd2l0aCB5b3VyICJsIiBl eGFtcGxlLCB0aGF0DQo+Pj4gY291bGQgYmUNCj4+PiANCj4+PiAgIFsgeyJibiI6ICIvY29sbGVj dGlvbjEvIiwgIm5leHQtb2JqZWN0IjogImUifSwNCj4+PiAgICAgW3sibiI6ICJpdGVtMSIsICJz diI6ICJ2YWx1ZTEifSwgLi4uXSwNCj4+PiAgICAgeyJuZXh0LW9iamVjdCI6ICJsIn0sDQo+Pj4g ICAgIFt7ImhyZWYiOiAiaXRlbTEiLCAuLi59LCAuLi59DQo+Pj4gICBdDQo+Pj4gDQo+Pj4gQXMg c2FpZCwgaXQncyBub3QgcHJldHR5LCBub3Igd2hhdCBJJ2QgZW5kb3JzZSBhcy1pcywgYnV0DQo+ Pj4gZXh0ZW5zaWJpbGl0eSBhbmQgZWFzeS10by1wYXJzZSBzZXF1ZW5jZSBkb24ndCBuZWNlc3Nh cmlseSBjb25mbGljdC4NCj4+PiANCj4+PiBDb25jZXJuaW5nIGZvY3VzIG9mIFNlbk1MOg0KPj4+ IA0KPj4+IFNpbXBsZSBjb2xsZWN0aW9ucyBzZWVtcyB0byBiZSBhIGdvb2Qgb3V0bGluZTsgd291 bGQgeW91IGFsc28gYWdyZWUgdG8NCj4+PiAic2ltcGxlIGNvbGxlY3Rpb25zIG9mIHJlc291cmNl IHJlcHJlc2VudGF0aW9ucyBhbmQgdGhlaXIgbWV0YWRhdGEiPw0KPj4+IA0KPj4+Pj4gV2hhdCBk byB5b3UgdGhpbmsgb2YgdGhlIGFib3ZlIGFycmFuZ2VtZW50Pw0KPj4+PiANCj4+Pj4gSSB0aGlu ayBpdOKAmXMgYSBzdWJzdGFudGlhbCBjb21wcm9taXNlIGluIHRoZSBhYmlsaXR5IHRvIHJlcHJl c2VudA0KPj4+PiBkYXRhIHN0cnVjdHVyZSB0byBnZXQgc3RyZWFtaW5nIHByb2Nlc3NpbmcgYWJp bGl0eS4gQnV0IEkgZG8gbGlrZSB0aGUNCj4+Pj4gaWRlYSBvZiBhIOKAnG924oCdIGVsZW1lbnQg Zm9yIG9iamVjdCB2YWx1ZXMuDQo+Pj4gDQo+Pj4gRG9lcyB0aGF0IHJlZmVyIHRvIHRoZSBuZXcg c2VyaWFsaXphdGlvbiBmb3JtYXQgaW4gZ2VuZXJhbCBvciB0bw0KPj4+IHBhY2tpbmcgdGhlIGxp bmsgbGlzdCBpbnRvIGFuIGVudGl0eSByZXNwb25zZSBpbiBwYXJ0aWN1bGFyPyBJbiB0aGUNCj4+ PiBsYXR0ZXIgY2FzZSwgcGxlYXNlIGVsYWJvcmF0ZSAtLSB0aGUgbGF0dGVyICJoYXBwZW5lZCIg d2l0aCB0aGUNCj4+PiBpbmZyYXN0cnVjdHVyZSBJJ3ZlIGJlZW4gdXNpbmcgKHVuZGVyIGNlcnRh aW4gY29uZGl0aW9ucywgbXkgYmF0Y2gNCj4+PiByZXNvdXJjZXMgY29udGFpbiB0aGVpciBhcHBs aWNhdGlvbi9saW5rLWZvcm1hdCBhcyAicyI6IGVudHJpZXMpLCBJJ3ZlDQo+Pj4gZm91bmQgaXQg cHJhY3RpY2FsLCBhbmQgaXQgd291bGQgY29tZSBpbiBtdWNoIG1vcmUgaGFuZHkgd2l0aCAib3Yi OmxpbmstDQo+PiBmb3JtYXQranNvbi4NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMNCj4+PiBDaHJp c3RpYW4NCj4+PiANCj4+PiAtLQ0KPj4+IENocmlzdGlhbiBBbXPDvHNzICAgICAgICAgICAgICAg ICAgICAgIHwgRW5lcmd5IEhhcnZlc3RpbmcgU29sdXRpb25zIEdtYkgNCj4+PiBmb3VuZGVyLCBz eXN0ZW0gYXJjaGl0ZWN0ICAgICAgICAgICAgIHwgaGVhZHF1YXJ0ZXI6DQo+Pj4gbWFpbHRvOmMu YW1zdWVzc0BlbmVyZ3loYXJ2ZXN0aW5nLmF0ICB8IEFyYmVpdGVyZ2Fzc2UgMTUsIEEtNDQwMCBT dGV5cg0KPj4+IHRlbDorNDMtNjY0LTk3LTkwLTYtMzkgICAgICAgICAgICAgICAgfCBodHRwOi8v d3d3LmVuZXJneWhhcnZlc3RpbmcuYXQvDQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCBBVFU2ODQ3NjYxNA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gY29yZSBtYWlsaW5nIGxpc3QNCj4+IGNvcmVAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1h aWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29yZQ0KDQo= From nobody Thu Nov 19 12:08:22 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46B1B31A6 for ; Thu, 19 Nov 2015 02:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.585] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_qL_k1BDXbX for ; Thu, 19 Nov 2015 02:37:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659D81B31A1 for ; Thu, 19 Nov 2015 02:37:31 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 0D433181B00; Thu, 19 Nov 2015 11:37:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1447929450; bh=YUxmJkd+/FYotlzXzE/ZDvUUKSXmBR6OViuasLzonGc=; h=From:Date:To; b=g1PDXTIsl0HG3hT4gsF5MBPcWZG8LyQD395q7vfVKUiut7+UdJcBnrfsKeorIOzhG ecjJ2TD9Ld/ocp84h9QkEDjzR9e+7DSiSS932sRrZ0l9kRf4znW4US/FRHXs6Qmhq3 GU54s3loUPxymUtkVmWJ9QBUzMPOQBLn5zJnhDYY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Ladislav Lhotka In-Reply-To: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> Date: Thu, 19 Nov 2015 11:37:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56C321F1-3905-489A-A398-4AEF1E768B68@nic.cz> References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.3096.5) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Thu, 19 Nov 2015 12:08:21 -0800 Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 10:37:32 -0000 > On 19 Nov 2015, at 11:00, peter van der Stok = wrote: >=20 > Hi CoOL authors. >=20 > I have looked at your section 5, and see an enormous overlap with the = CoMI section 6. Actually the two proposals are almost completely = interoperable, with a few exceptions. Much of the CoMI proposal is based = on the work of Ladislav Lhotka, described in = draft-ietf-netmod-yang-json. CoMI refers to this draft and uses it = extensively. In the CoOL draft the yang-json draft is ignored. That is a = pity because you are redoing much of the work already done in the = yang-json draft. In the CoMI draft we used the results of yang-json = draft, exchanged the YANG name by the hash value, and passed it through = the diagnostic JSON to CBOR translator. Quite a satisfactory and elegant = solution. > Below, I have summarized my comparison between CoMI YANG to CBOR and = CoOL YANG to CBOR. Please check for omissions and mistakes. > Differences concern Binary byte string and Bits. The CoMI choice of = CBOR type is derived from yang-json, and I should like to hear the = opinion of Ladislav on this aspect. Isn't it just an error? The CoOL draft says: Leafs of type binary MUST be encoded using a CBOR byte string data item (major type 0). However, RFC 7049 defines major type 0 as unsigned integer. > Other differences concern decimal64, and int; but I expect that is an = oversight in the CoOL draft. > A major difference is the encoding of lists and list instances; I = discuss that in a separate e_mail. > Given the overlap of work and the need for the expertise of the netmod = WG, I recommend that a YANG CBOR draft is submitted to the netmod wg and = uses as much as possible the contents of yang-json draft. Alternatively, = I can imagine that CBOR mapping is added to the yang-json draft if the = author, Ladislav Lhotka, and the WGs agree with that. As Juergen wrote in his reply, there are good reasons not to do that. Lada >=20 > Greetings, >=20 > Peter > = __________________________________________________________________________= ____ > Comparison of draft veillette-core cool, denoted with CoOL > With draft vanderstok-core-comi, denoted with CoMI > And draft ietf-netmod-yang-json, denoted with yang-json > Simple YANG type can be : > Binary byte string: CoMI, major type 2; = CoOL, major type 0 > Bits: CoMI, array of text; = CoOL, major type 0 > Boolean: CoMI, major type 7 (20,21); = CoOL, major type 7 (20,21) > decimal64: CoMI, major type 0 (pos) and = 1(neg); CoOL major type 0 > empty: CoMI major type 7(22); = CoOL major type 7(22) > enumeration: CoMI, major type 0; = CoOL major type 0 > identityref: CoMI, major type 3; = CoOL major type 3 > int8, int16, int32, int64: CoMI, major type 0 (pos) and = 1(neg); CoOL major type 0 > leafref: CoMI, follows leaf type; = CoOL follows leaf type > string: CoMI, major type 3, = CoOL major type 3 > uint8, uint16, uint32, uint64: CoMI, major type 0; = CoOL major type 0 >=20 > In netmod-yang-json draft JSON objects are used: > JSON object :=3D { name: JSON object}, where name is a string. For = CoMI and CoOL the name can be an integer which is valid for diagnostic = JSON used for CBOR, giving: > CBOR object :=3D {integer: CBOR object} >=20 > Leaf: > Yang-json, Name : value, where name is the string identifier of the = leaf, and value of Simple YANG type > CoMI: major type 5 containing: uint64, value; CoOL: not defined >=20 > Union: > Yang-json, use corresponding media type for type of value > CoMI, use corresponding CBOR type; CoOL, use corresponding CBOR type >=20 > anyxml, > YANG-json, value can be of any type. > CoMI, not applicable; CoOL, can be any CBOR type >=20 > Anydate, > Yang-json, follows container > CoMI, not applicable, CoOL, not applicable >=20 > container, > yang-json, name: JSON object > CoMI: major type 5; CoOL, major type 5 >=20 > leaf-list > yang-json, name: [ value 1, value 2,=E2=80=A6=E2=80=A6] > CoMI, major type 4, CoOL, major type 4 >=20 > List > Yang-json, name:[ JSON object1, JSON object2, =E2=80=A6.] > CoMI, major type 5 of major type 5, CoOL, major type 4 of = major type 5 >=20 >=20 >=20 > --=20 > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Nov 19 15:06:20 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDBF1B36F8 for ; Thu, 19 Nov 2015 15:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeOmyX6hkyQE for ; Thu, 19 Nov 2015 15:06:17 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 C63E71B36F7 for ; Thu, 19 Nov 2015 15:06:16 -0800 (PST) Received: by lfaz4 with SMTP id z4so58307163lfa.0 for ; Thu, 19 Nov 2015 15:06:14 -0800 (PST) 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:content-type; bh=KOfuxSJCNjcmtTAZ29ls2fgqzQiUNamNoteNFpmbauM=; b=mi5KdSudaGXtbxFJG8RIjlphqdmd1DC0/l7z2PyZuSyU1ta3yzXJ0AbcTUIplEzP0/ 0cmT4PZnaRjBKoFWQO7CJl7SIMKjK+2ysdETf0peEo6+wyBbsPt7zeLaa16LZjFp/J3B ulFNieQiYot1wxq4c1xX838Mzv/EIoHqmgM2gJaKSStiz/WBnGW6yrG/OB8iFsN/UAQx q7pBVi2xegHKCMCBE+7eJBFXR8E/KwwSkpAJCyz5rQk+o+zjPee4sfY7VUATGzABIJKa 4pjW5+hig0uIG8oPlLAuHxyhW2FhaMssAOQmsHPpVt2sVrqQlZJoD1BsbLlYFwYq3S/B nkgw== 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:content-type; bh=KOfuxSJCNjcmtTAZ29ls2fgqzQiUNamNoteNFpmbauM=; b=l73znYnucvWvOSxTSUK4CEuTckQgMQLfE8o8aGWSqct0YD/qdoN4L8aZYMkVdG0T5d X+CLzCoK4N/FsWYT7kAxrOqRL1mN0Jgeg6EeQyku6tfGV7j/aGq7G2A00mpl7VuNKCch LfKhS7PkYb65xR/rxi7aalIArM/0nTGyuyOauaOGPQoltzzOZfgiH/wNsVt4UL1Srx7b jIsiYguLiMzJ83AcKj7Z46bTF1Hnt3nWs/Dvd25TXX5Ph+j37B82/lTU3zQ2HTqV5M7z +UATVe7eXZIARFLBBnv7/pRLGMDnIf5hV/GO+zb7W9bI8F0Q1f6qrxtgQyEt6ms6Wkxl NLLA== X-Gm-Message-State: ALoCoQlpWobaOnP3UhLgbYGYD965HTRN6hZSNI9usA3OG/70LkTZamzG78tXy5dBzOZlKnQkk9ML MIME-Version: 1.0 X-Received: by 10.25.85.200 with SMTP id j191mr4508345lfb.131.1447974374799; Thu, 19 Nov 2015 15:06:14 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 19 Nov 2015 15:06:14 -0800 (PST) In-Reply-To: <564DFAD7.1000800@tzi.org> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@tzi.org> Date: Thu, 19 Nov 2015 15:06:14 -0800 Message-ID: From: Andy Bierman To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11424d0c4111350524eccee8 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 23:06:18 -0000 --001a11424d0c4111350524eccee8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2015 at 8:37 AM, Carsten Bormann wrote: > Andy Bierman wrote: > > I think the term "constrained" is not widely agreed upon in the IETF. > > No. But we are using it in the sense of RFC 7228 here. > OK. So that means the scope includes constrained networks, not just constrained nodes. I am interested in using CoMI as a replacement for RESTCONF in constrained networks where TCP doesn't really work. I want to use the same "content layer" and code for that content across the board. That means the exact same YANG data models, without exception, and the translation from RESTCONF features to CoMI features must be loss-less. The protocol, messaging, and transport layers can all change as needed. I realize this is not what might work best for a constrained node. Maybe we can build 2 separate protocols out the parts that have been proposed. I don't see managed IDs as a general solution, but IMO constrained nodes will never be using the same modules that are written for networking equipment. > Gr=C3=BC=C3=9Fe, Carsten > Andy --001a11424d0c4111350524eccee8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 19, 2015 at 8:37 AM, Carsten Bormann <= cabo@tzi.org> wrote:
Andy Bierman wrote:
> I think the term "constrained" is not widely agreed upon in = the IETF.

No.=C2=A0 But we are using it in the sense of RFC 7228 here.

OK. So that means the scope includes constrained netw= orks, not just
constrained nodes. I am interested in using CoMI a= s a replacement
for RESTCONF in constrained networks where TCP do= esn't really work.

I want to use the same &quo= t;content layer" and code for that content across the board.
That means the exact same YANG data models, without exception, and the tra= nslation
from RESTCONF features to CoMI features must be loss-les= s.=C2=A0 The protocol,
messaging, and transport layers can all ch= ange as needed.

I realize this is not what might w= ork best for a constrained node.
Maybe we can build 2 separate pr= otocols out the parts that have been proposed.
I don't see ma= naged IDs as a general solution, but IMO constrained nodes
will n= ever be using the same modules that are written for networking equipment.



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


Andy

--001a11424d0c4111350524eccee8-- From nobody Thu Nov 19 22:36:03 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260C21A8847 for ; Thu, 19 Nov 2015 22:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEUu5uu86YVf for ; Thu, 19 Nov 2015 22:36:00 -0800 (PST) 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 7E8B91A8849 for ; Thu, 19 Nov 2015 22:36:00 -0800 (PST) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4C64617209D; Fri, 20 Nov 2015 07:35:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id tXH6u5zVmmQv; Fri, 20 Nov 2015 07:35:57 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C5D311720A3; Fri, 20 Nov 2015 07:35:55 +0100 (CET) Message-ID: <564EBF4A.8010405@tzi.org> Date: Fri, 20 Nov 2015 07:35:54 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Andy Bierman References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@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 Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 06:36:02 -0000 Andy Bierman wrote: > [...] IMO constrained nodes > will never be using the same modules that are written for networking > equipment. Is that so? Why wouldn't I use a couple of items from, say, RFC 7317 (or 7277) in my constrained node? In the end these are just resources that I add to my resource tree. Of course, cherry-picking may require some form of subsetting that may not yet be part of the NETCONF approach. Gr眉脽e, Carsten From nobody Fri Nov 20 00:41:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F121B2AD6 for ; Fri, 20 Nov 2015 00:41:09 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2KlRNJgM0FY for ; Fri, 20 Nov 2015 00:41:04 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D761B2AC2 for ; Fri, 20 Nov 2015 00:41:03 -0800 (PST) Received: from AM3PR06MB146.eurprd06.prod.outlook.com (10.242.245.15) by AM3PR06MB500.eurprd06.prod.outlook.com (10.242.113.146) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 08:40:43 +0000 Received: from DB4PR06CA0038.eurprd06.prod.outlook.com (10.160.40.166) by AM3PR06MB146.eurprd06.prod.outlook.com (10.242.245.15) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 08:40:41 +0000 Received: from AM1FFO11FD004.protection.gbl (2a01:111:f400:7e00::196) by DB4PR06CA0038.outlook.office365.com (2a01:111:e400:9851::38) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Fri, 20 Nov 2015 08:40:41 +0000 Authentication-Results: spf=pass (sender IP is 146.108.200.10) smtp.mailfrom=tridonic.com; yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=bestguesspass action=none header.from=tridonic.com; Received-SPF: Pass (protection.outlook.com: domain of tridonic.com designates 146.108.200.10 as permitted sender) receiver=protection.outlook.com; client-ip=146.108.200.10; helo=ATDOAGMSX01.itiso.net; Received: from ATDOAGMSX01.itiso.net (146.108.200.10) by AM1FFO11FD004.mail.protection.outlook.com (10.174.64.86) with Microsoft SMTP Server (TLS) id 15.1.331.11 via Frontend Transport; Fri, 20 Nov 2015 08:40:40 +0000 Received: from ATBRAGMSX02.itiso.net ([169.254.2.220]) by ATDOAGMSX01.itiso.net ([146.108.41.67]) with mapi id 14.03.0248.002; Fri, 20 Nov 2015 09:40:38 +0100 From: Somaraju Abhinav To: Andy Bierman , Carsten Bormann Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwbW5jNwRAHeU+Rg/6jmUcLNJ6gTL6AgAAcVgCAAOkigIAAHgWEgAB6WYCAATLOoYAAW9oAgAAFAYCAAGyNAIAAqidQ Date: Fri, 20 Nov 2015 08:40:38 +0000 Message-ID: <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AD509@ATBRAGMSX02.itiso.net> References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@tzi.org> In-Reply-To: Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.108.41.149] Content-Type: multipart/alternative; boundary="_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AD509ATBRAGMSX02itis_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD004; 1:NHEPZXZzH45PiE7xeXp1Kot6XmC8ruUERo8B5pTI9v4zx9gfz1pTOtZSF17iBZJ7BU39unJIZlOyMJp/Ld06LZP5yz+to9KAWNVZcUiJSKWhoAuladZdLWOAyr5L0Q19lW9JO41kNg6T69ANNMtJ9jTECTd8TVGs/mjXCL7K3QjFSMvQg/qwvBF7keHIbFoTFNahEdzXvfe6bY9S1IU4Ye6fTLMtJ9Bdeocy/J4tv+WDoQ/eBMPOPOl8BHLRxSlmJYUy1h2h4LWQEvz0YPD3D8uoHBtr9iaDcWfQeMAe9PdH65I0fI1Z+/2VAfSgz/I88HzgbqL3rgQyZ9pcLD5t8k0B2nDVZeD+zjj+BmhYV1o= X-Forefront-Antispam-Report: CIP:146.108.200.10; CTRY:AT; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(199003)(24454002)(189002)(377454003)(51444003)(5007970100001)(11100500001)(5003600100002)(6806005)(2920100001)(104016004)(106116001)(2900100001)(15975445007)(87936001)(3846002)(55846006)(5008740100001)(102836003)(106466001)(790700001)(6116002)(586003)(66066001)(33656002)(5890100001)(5004730100002)(69596002)(84326002)(26826002)(512874002)(5001920100001)(300700001)(81156007)(86362001)(2950100001)(92566002)(19625215002)(19300405004)(16236675004)(53416004)(189998001)(19580395003)(19580405001)(54356999)(50986999)(5001960100002)(76176999)(5001770100001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR06MB146; H:ATDOAGMSX01.itiso.net; FPR:; SPF:Pass; PTR:unknown.zgrp.net; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB146; 2:Nimk7p5QvaMaIvg+G9L/hGN7pd+9E0f43UBECwFQDw6A7EsHhaNkWK0rbGpoGIavQiyiXn3wg+6dQnky46JD/k3CSpuB5H5nIfgPfP5T0SAZb4n66+h3M94Upgo0BWl5wbx6QNpGsmyG9SnUL669+RGGe9tTnzngb7rhFq+Bqpc=; 3:fQNNBpK0Je4fVv/mykC6AuGAXAGDA6QIZ7p41n50eVDTkwXde5UcpzPtBFc2eWys6VlbT/hqdkx19yGZy6iodTd6dWNoQ5rI+09MMWB0LzYXXvX6UM4A0JSaXbZaHqguxEvIAxBLzgMivy6lsTlp1JwG23EmUxL/aOa+Haqj44tp7kEFUE6/uNBqnvZQdT+9cuzx+T4w3jnMHjajZjrhUa0jgLR+3b0UMgIPqSxirSsZSI5rdMuVu2wqIGOgRZ09JW6J2stndaHi0SJqXbY8Vg==; 25:D/MBpyzl5Yo5DZV+AL238XogAnAObntKkGUvcJvcdbQ5YqYIqnUFX8OZ7oveuLp2ZBX4Ay7tFcKFSVWdxlDzBUOQ7vfB7L3K8EPSTTTBF9BWsBmN4o3FzFDlp1nlqFEFR5VAWVjZRoU2AkMHsa9EPPGQId0GNseeYWyN4UEfagImOjfY4I3ZCQb3WUxCx1Ja3EWsiOW3MdeV64EKbIxmVxUI4e2HMVu/VU3ix9ROJ4n3yMKWAFNjVInR2PxZ1geh+YJyrHnoHepncC99W6lKhQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:AM3PR06MB146; X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB146; 20:l7w5An8Y/5eUia3ZXRss9Icn79UxWi5pjHWcbRpK1NVVleR6MV5ctShYQEg8UcgkDP7Kf8yIZafsad9QjOqOWu5MRbF292d1Ff3gzt/cqzOTHFOZhMtp8rQeBFgbSLbj1+lHu4N5iHQTDhX88hLJat0Jr7VZSCTDsRCMCjG/BVUgC7/pNJM8N3/CKC2DqzS5EcLphNmwBcDKtBaQFwSI3Mp0XZkWT3pJUrX5AXJ1DK08XkJyLjrs6wqf378SHWpl16KP1yn1QRc3S1HMQ9ilGwtGAB4K2ioLh2fohlekM7mkWBs9Trcke6DwlXiKGPAZenxk4oKs3WuB7b9kXLEe20Bygev5H0cowU5hyzGpGDE8sq5hKoXhLaCy/ZuaU6UZtQG0bhMwnpKtsmFGyiRJxwjhjBmSoeKDKqUDpXh0mGEZdkW+YTkyqxj2RUNSslJbLJJUOLnLFhJkkHPq7w4BQUf5tgeft9LLw1FlCcQz/RKG+5FBg2cc9h/Yj9HyOyc6; 4:wOcnxVN0i7CIU859KRGTmir6rko2UxefCDPOGAVIRcE0weQVgSHfliLOLs+2XegzgHtVXhSPH7vfsxNaY5dqMhV2yOZL9LoYv0+JWSMpXcNSKg5HxTNjMWLLy5+tZvCBObTqKI5QgidLwJjjBb+liX1UUkOwlslaZLji/uzEcBwdkbrHE8UMCKJ4lvZKyz046qujhZ5+mfFphJhMBqMskZje8iLR3yrgNMzlpzbZc0S/sThz9aDkZULNDC2CNCAtbS+qSfNjON2w028LBXGO1n9wq/id4DDt+wMYiVGitvK72faEYRD1Ob5br2bBHxSj7hw3JXPtXpOVagT/4o3110w7mq0tZ5a9lNmemJKj60apUQuG3xY2yuHlRvOyZzhl/v920ypFKFtTIEMhaFuv0A== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:AM3PR06MB146; BCL:0; PCL:0; RULEID:; SRVR:AM3PR06MB146; X-Forefront-PRVS: 07665BE9D1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM3PR06MB146; 23:usA+Wqq2GEGRBdWcqlS4pY9QpExqPrakJnpv9nrhBH?= =?us-ascii?Q?tIFnEaDMboyK5L79wLFwEjEK9Nvp6kuiewY1GZJQpKS+lR51pLsEqbrUahVC?= =?us-ascii?Q?EMGrwxLrGzsmAi2TWphzKI3UjL+SA4iO0rHz+UDbOdubhjY4hY+isrWXMINA?= =?us-ascii?Q?ucPefsE8/x2b9Df0I5SGk3kX70AHWmWbvZBxkDXhR7TBaJUIbZmHj3vxq3ab?= =?us-ascii?Q?KB0+U89mIVmD5c9UPtqa39RnaD1ockV1BXYOYi3pkpTll1ivSVKBgjpnOSyy?= =?us-ascii?Q?P3bHsS0/mvCmWVM4OmgZ9FQTiNWVrCmc7M3+wBwVQUdHFWxYtu6Z3VBZ36Bi?= =?us-ascii?Q?+yWeE+n/HhTZpXqOE2CuDN6Wdp7tgfKtYVieTjgAoZ/SCmCXTudLCJuGUue/?= =?us-ascii?Q?LxUuwnQtCDe+IAR9m8TsyjEpBRFkh1QbvZvAqcupti8b8YoQeKvaBR3L9y8R?= =?us-ascii?Q?RpnU+HvLFrsZcgHAZiLVMHcvizHuBD7qZvqtkZczJeg8GAJ+Hk1pF8rV9MIJ?= =?us-ascii?Q?Ic/atxQKcDq5eLtAofGlXFLEY2a6uP4tgpRV9bvZiy0brLsMF8yCFcZoOI3z?= =?us-ascii?Q?lzS5g0UY2erV/IRJAghB+p1tmpaz62YKW+a2yyy4m5I47WqniEyC+VtIzLbe?= =?us-ascii?Q?t+rJ8+KUpaVB6imRjSpcoSHUxq8b+8DoM99aPdGqTEyXZG52eG97A+JQuRIQ?= =?us-ascii?Q?U4FBZazJiMuErMebWUAm0SG9D31gbG/pTpqtJl4b0IdYW/5n8qqHi1gJ3lKN?= =?us-ascii?Q?Bfq5wi//dfte7GnK1Hhc1eBurEajJsZM6Ez7djN6eEd9SwH1+ALn+2+Jko9M?= =?us-ascii?Q?M1RWpY1RIt0A14hpwzIbiLd3hT/UFSxLumUZTsA9UAGgtaxpK8siN9QSM7TA?= =?us-ascii?Q?qVw0IpW0/M2GUQ1mEfaMcSDet/9L6CAis8o4emraph1v5Acdp7BMh/HtbFFV?= =?us-ascii?Q?3mDqG8Mc+ZjqUuHTHRTsytR/r8g5ml7kvk546VJAM6DtEqqMiJHuOCBB0VMM?= =?us-ascii?Q?v8aozBdf8HSoypnFpe0el2pr+FWXTleamE9EL+AowOB2si2W7R8tBhkkhDZs?= =?us-ascii?Q?d8OOBGo1Y/nOOYPX/t1e8YCtq89Da9HofeZQO4vegMPbHtzSCqq4XPKFRpPs?= =?us-ascii?Q?2FKXV05/98otwjjfohx8nNCLyKeWDHBl4Lf8oJz7qDBwYUul+c5w0BcffOL1?= =?us-ascii?Q?3wXFX+L4eEqJuozV7PotczrSVflVjkPTMHpYfH+9sazZF8bB1cXbjgsGxNsH?= =?us-ascii?Q?fSlj9WGyXCM584leQrJekN0y3Udl09oy6HmVp/9N1ErrPy6XXbRsFKd+1apw?= =?us-ascii?Q?FQzqmGDb8SsmWlMvM1s6XUVQ/FIMzf8xGwXvxnKYMW+oTq4dPUipOvNfjpob?= =?us-ascii?Q?TcxEC6/mWrdkucJ5Wp6lwzaOsJ8febRqCsOTmTv1/CTS85?= X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB146; 5:LOqzIJ0o0Uc7OpePBYsqHvWAlq0ObSCo8Hqp+OZycBoqO1mJ4GXpvPiPJINLf5QsiUcrYVjJsLCV/hcY5l8vnXcaowcmYZnuwataFcuCQOdS+MSY3T+IGK+NYJBq1JwlsNBWEB1DHb9vXhK5j7xNpw==; 24:NPAuWOB5j+4FpLu8Ii1eOB3rvV9VEK/OPpVqLqB0YN0HNzetUcy8Xz826xVszepFzqu71zCni3Ti+Rmpx+1dLzAe0t26Jxtgiec1Ah7C4lo=; 20:BkKS/nSX4HANP9sX6lx/WvD36LkQerpyOWXGdkmYUF5L80gUCNJOU3dg++EduwiZ8FwWTuMNQ/S0NjEom3NDCw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Nov 2015 08:40:40.7517 (UTC) X-MS-Exchange-CrossTenant-Id: 8b206608-a593-4ace-a4b6-ef1fc83c9169 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8b206608-a593-4ace-a4b6-ef1fc83c9169; Ip=[146.108.200.10]; Helo=[ATDOAGMSX01.itiso.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR06MB146 X-Microsoft-Exchange-Diagnostics: 1; AM3PR06MB500; 2:e+wKq6APZxPa5jx3iEBrdUqqijiDa9+WH0F+cqLr0lYBxrRknMz5HEoeLjk4mucVnLjE3LS1kmlZFMW7yfQUqvuiIFZmidatym2IQaYepwqNwj7oVB6WfX4udvhMWzScNgwAThDdUqqFDtBUPksxYLaHrOeDKn/3PPPwazPrxf4=; 23:j1Urj9BZ+rUQFm40UMmmzBBJpfXeZdVihsF2v9XojB9MXazm1NH0aI9Z/nAm0n8vU1qvjU2GlnAM+dE7oPtNDMnESk4fLHNxtxA23f1yCDXM1GiaOf4i7ZQ3jxSRbzu6vM3IB6no7coZaRkEQwYyVWi7kml+WyZdbzEZ7hYPoIFTy+b3aLnZs4syhrPfQLFe X-OriginatorOrg: tridonic.com Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 08:41:10 -0000 --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AD509ATBRAGMSX02itis_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KQWJvdXQg4oCcT0suIFNvIHRoYXQgbWVhbnMgdGhlIHNjb3BlIGluY2x1ZGVz IGNvbnN0cmFpbmVkIG5ldHdvcmtzLCBub3QganVzdCBjb25zdHJhaW5lZCBub2Rlcy4gSSBhbSBp bnRlcmVzdGVkIGluIHVzaW5nIENvTUkgYXMgYSByZXBsYWNlbWVudCBmb3IgUkVTVENPTkYgaW4g Y29uc3RyYWluZWQgbmV0d29ya3Mgd2hlcmUgVENQIGRvZXNuJ3QgcmVhbGx5IHdvcmsu4oCdDQpb QVNdIEkgd2FzIGhvcGluZyB0byB1c2UgQ29NSSBhcyBtdWNoIG1vcmUgdGhhbiBhIHJlcGxhY2Vt ZW50IGZvciBSRVNUQ29uZiBpbiBjb25zdHJhaW5lZCBuZXR3b3JrLiBJbiB0aGUgQ29NSSBkcmFm dCwgeW91IG1ha2UgYSBwb2ludCBvZiBjb21wYXJpbmcgQ29NSSB0byBMV00yTSBhbmQgcG9pbnQg b3V0IHRoZSBhZHZhbnRhZ2VzLiBBcyBmYXIgYXMgSSBhbSBhd2FyZSwgTFdNMk0gaGFzIG5vdGhp bmcgdG8gZG8gd2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kL29yIHJlc3Rjb25mLiBMV00yTSBp cyB1c2VkIHRvIHJlYWxseSBtYW5hZ2UgY29uc3RyYWluZWQgZGV2aWNlcyBhbmQgYXBwbGljYXRp b25zIHRoYXQgY29uc3RyYWluZWQgZGV2aWNlcyB1c2UuIFNvLCB0aGlzIGNvbXBhcmlzaW9uIG9m IENvTUkgd2l0aCBMV00yTSBpcyB2ZXJ5IG1pc2xlYWRpbmcuIEkgcGVyc29uYWxseSB3YW50IHRv IHVzZSBDb01JL0NvT0wgdG8gcmVwbGFjZSBpbnN0ZWFkIG9mIExXTTJNIGFuZCBJIHNlZSBncmVh dCBiZW5lZml0cyBpbiBkb2luZyBzby4gTGlrZSBpdCBvciBub3QsIFlBTkcgbG9va3MgbGlrZSBh IGRhdGEgbW9kZWxsaW5nIHRvb2wgdGhhdCBjYW4gYmUgdXNlZCBmb3Igc2V2ZXJhbCBkaWZmZXJl bnQgcHVycG9zZXMuDQoNCk1heWJlIHdlIGNhbiBidWlsZCAyIHNlcGFyYXRlIHByb3RvY29scyBv dXQgdGhlIHBhcnRzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkLg0KW0FTXSBNYXliZSB0aGlzIG1h a2VzIHNlbnNlIGJ1dCB3ZSBzaG91bGQgdHJ5IHRvIG1lcmdlIHRoZSB0d28gaWYgcG9zc2libGUu DQoNCkFib3V0IOKAnEkgZG9uJ3Qgc2VlIG1hbmFnZWQgSURzIGFzIGEgZ2VuZXJhbCBzb2x1dGlv biwgYnV0IElNTyBjb25zdHJhaW5lZCBub2Rlc+KAnQ0KW0FTXSBJIHBhcnRseSBhZ3JlZSBhYm91 dCB0aGlzIGFzc2Vzc21lbnQuIEkgdGhpbmsgdGhhdCBoYXZpbmcgYSBjZW50cmFsIHJlZ2lzdHJ5 IGZvciBhbGwgbWFuYWdlZCBJRHMgaXMgaW5kZWVkIHVucmVhbGlzdGljIGFuZCB3aWxsIG5vdCB3 b3JrIGluIHRoZSBsb25nIHJ1bi4gSG93ZXZlciwgSSBzZWUgdGhhdCBDb01JL0NvT0wsIGlmIHVz ZWQgZm9yIGFwcGxpY2F0aW9uIG1hbmFnZW1lbnQsIHdpbGwgYmUgYSB0b29sIHRoYXQgb3RoZXIg U0RPcyBzdWNoIGFzIE9NQSBvciBJUFNPIGNhbiByZXVzZS4gSSBleHBlY3QgdGhhdCBpZiB3ZSBw cm92aWRlIHN0YW5kYXJkIG1ldGhvZHMgZm9yIGFuIFNETyAoZS5nLiB1c2UgcmVzb3VyY2UgdHlw ZSB0byBpbmRpY2F0ZSB0aGUgdHlwZSBvZiBZQU5HIG1vZHVsZSkgdGhlbiB0aGVzZSBTRE9zIGNh biBtYW5hZ2UgSURzIHRoYXQgYXJlIHJlbGV2YW50IHRvIHRoZSBTRE8uDQoNCkFib3V0IOKAnGJ1 dCBJTU8gY29uc3RyYWluZWQgbm9kZXMgd2lsbCBuZXZlciBiZSB1c2luZyB0aGUgc2FtZSBtb2R1 bGVzIHRoYXQgYXJlIHdyaXR0ZW4gZm9yIG5ldHdvcmtpbmcgZXF1aXBtZW50LuKAnQ0KW0FTXSBN YXliZSBjb25zdHJhaW5lZCBub2RlcyB3aWxsIG5vdCB1c2UgYWxsIHRoZSBtb2R1bGVzIHdyaXR0 ZW4gZm9yIG5ldHdvcmtpbmcgZXF1aXBtZW50LiBIb3dldmVyLCBJIGFtIHN1cmUgc29tZSBvZiB0 aGVtIGNvdWxkIGJlIGFuZCB3aWxsIGJlIHVzZWQuDQoNCkFib3V0IOKAnFdlIHBsYW4gdG8ganVz dCB1c2UgTkFDTSB0byBjb25maWd1cmUgd2hhdCBhIGNsaWVudCBpcyBhdXRob3JpemVkIHRvIGFj Y2VzcyB3cnQvIG1hbmFnZW1lbnQgZGF0YSBhbmQgb3BlcmF0aW9ucy4gIEFnYWluLCBob3cgbXVj aCB2YWx1ZSBpcyB0aGVyZSBpbiByZWludmVudGluZyBzdHVmZj/igJ0NCltBU10gSSBhbSBub3Qg c2F5aW5nIHRoYXQgTkFDTSBzaG91bGQgbm90IGJlIHVzZWQuIEkgYW0ganVzdCBzYXlpbmcgdGhh dCB3ZSBzaG91bGQgdGhpbmsgYWJvdXQgaXQgYW5kIGlmIE5BQ00gd29ya3MgYXMgaXQgaXMgdGhl biBzdXJlIHdlIGNhbiByZXVzZSBpdC4NCg0KQWJvdXQg4oCcVGhpcyBkZXNjcmliZXMgd2hhdCBp cyBhbGxvd2VkIHRvIGNoYW5nZSBpbiBhIG5ldyByZXZpc2lvbiBvZiBhIG1vZHVsZS4gTm90aWNl IGhvdyAicmVuYW1lIG9iamVjdCIgaXMgbm90IGluIHRoZSBsaXN0P+KAnQ0KW0FTXSBUaGUgY29v bCBtb2R1bGUgaWRlbnRpZmllciBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgdGhlIG5hbWUgb2Yg dGhlIFlBTkcgbW9kdWxlLiBJdCBpcyBhbiBleHRlbnNpb24gYW5kIHRoZXJlIGFyZSBubyBydWxl cyBhcyBmYXIgYXMgSSBrbm93IGluIFlBTkcgdGhhdCBzYXlzIHRoaXMgY2Fubm90IGNoYW5nZS4N Cg0KQWJvdXQg4oCcU3RhYmxlIGlkZW50aWZpZXJzIGFyZSB1c2VmdWwgYmVjYXVzZSBvbGQgY2xp ZW50cyBjYW4gY29udGludWUgdG8gd29yayB3aXRoIG5ldyBzZXJ2ZXJzLuKAnQ0KW0FTXSBPa2F5 LCBJIGNhbiBsaXZlIHdpdGggdGhpcyBleHBsYW5hdGlvbi4gTWF5YmUgd2UgY2FuIHRoaW5rIG9m IGF1dG9tYXRlZCBudW1iZXJpbmcgc2NoZW1lcyB3aGVyZSBkYXRhIG5vZGVzIGluIG5ld2VyIHZl cnNpb25zIGFyZSBhdXRvbWF0aWNhbGx5IGFzc2lnbmVkIElEcyBoaWdoZXIgdGhhbiBhbGwgcHJl dmlvdXMgdmVyc2lvbnMgaW4gdGhlIG1vZHVsZS4NCg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21h aWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBGcmVpdGFnLCAyMC4gTm92ZW1iZXIgMjAx NSAwMDowNg0KVG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IFNvbWFyYWp1IEFiaGluYXY7IENvcmUN ClN1YmplY3Q6IFJlOiBbY29yZV0gQ29NSSBDb29sIGRyYWZ0IHNwbGl0cw0KDQoNCg0KT24gVGh1 LCBOb3YgMTksIDIwMTUgYXQgODozNyBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8 bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KQW5keSBCaWVybWFuIHdyb3RlOg0KPiBJIHRo aW5rIHRoZSB0ZXJtICJjb25zdHJhaW5lZCIgaXMgbm90IHdpZGVseSBhZ3JlZWQgdXBvbiBpbiB0 aGUgSUVURi4NCg0KTm8uICBCdXQgd2UgYXJlIHVzaW5nIGl0IGluIHRoZSBzZW5zZSBvZiBSRkMg NzIyOCBoZXJlLg0KDQpPSy4gU28gdGhhdCBtZWFucyB0aGUgc2NvcGUgaW5jbHVkZXMgY29uc3Ry YWluZWQgbmV0d29ya3MsIG5vdCBqdXN0DQpjb25zdHJhaW5lZCBub2Rlcy4gSSBhbSBpbnRlcmVz dGVkIGluIHVzaW5nIENvTUkgYXMgYSByZXBsYWNlbWVudA0KZm9yIFJFU1RDT05GIGluIGNvbnN0 cmFpbmVkIG5ldHdvcmtzIHdoZXJlIFRDUCBkb2Vzbid0IHJlYWxseSB3b3JrLg0KDQpJIHdhbnQg dG8gdXNlIHRoZSBzYW1lICJjb250ZW50IGxheWVyIiBhbmQgY29kZSBmb3IgdGhhdCBjb250ZW50 IGFjcm9zcyB0aGUgYm9hcmQuDQpUaGF0IG1lYW5zIHRoZSBleGFjdCBzYW1lIFlBTkcgZGF0YSBt b2RlbHMsIHdpdGhvdXQgZXhjZXB0aW9uLCBhbmQgdGhlIHRyYW5zbGF0aW9uDQpmcm9tIFJFU1RD T05GIGZlYXR1cmVzIHRvIENvTUkgZmVhdHVyZXMgbXVzdCBiZSBsb3NzLWxlc3MuICBUaGUgcHJv dG9jb2wsDQptZXNzYWdpbmcsIGFuZCB0cmFuc3BvcnQgbGF5ZXJzIGNhbiBhbGwgY2hhbmdlIGFz IG5lZWRlZC4NCg0KSSByZWFsaXplIHRoaXMgaXMgbm90IHdoYXQgbWlnaHQgd29yayBiZXN0IGZv ciBhIGNvbnN0cmFpbmVkIG5vZGUuDQpNYXliZSB3ZSBjYW4gYnVpbGQgMiBzZXBhcmF0ZSBwcm90 b2NvbHMgb3V0IHRoZSBwYXJ0cyB0aGF0IGhhdmUgYmVlbiBwcm9wb3NlZC4NCkkgZG9uJ3Qgc2Vl IG1hbmFnZWQgSURzIGFzIGEgZ2VuZXJhbCBzb2x1dGlvbiwgYnV0IElNTyBjb25zdHJhaW5lZCBu b2Rlcw0Kd2lsbCBuZXZlciBiZSB1c2luZyB0aGUgc2FtZSBtb2R1bGVzIHRoYXQgYXJlIHdyaXR0 ZW4gZm9yIG5ldHdvcmtpbmcgZXF1aXBtZW50Lg0KDQoNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoN CkFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBUaGV5IG1heSBub3Qg YmUgZGlzY2xvc2VkIHRvIG9yIHVzZWQgYnkgb3IgY29waWVkIGluIGFueSB3YXkgYnkgYW55b25l IG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudC4gSWYgdGhpcyBlLW1haWwgaXMgcmVj ZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVkIGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhh dCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBzZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkg cmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkg dG8gc2NhbiBvciBvdGhlcndpc2UgY2hlY2sgdGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50 cy4NCg== --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AD509ATBRAGMSX02itis_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQW5k eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5BYm91dCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PSy4g U28gdGhhdCBtZWFucyB0aGUgc2NvcGUgaW5jbHVkZXMgY29uc3RyYWluZWQgbmV0d29ya3MsIG5v dCBqdXN0IGNvbnN0cmFpbmVkIG5vZGVzLiBJIGFtIGludGVyZXN0ZWQgaW4gdXNpbmcgQ29NSSBh cw0KIGEgcmVwbGFjZW1lbnQgZm9yIFJFU1RDT05GIGluIGNvbnN0cmFpbmVkIG5ldHdvcmtzIHdo ZXJlIFRDUCBkb2Vzbid0IHJlYWxseSB3b3JrLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzc2MDkyO21zby1zdHlsZS10 ZXh0ZmlsbC1maWxsLWNvbG9yOiMzNzYwOTI7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6 MTAwLjAlIj5bQVNdIEkgd2FzIGhvcGluZyB0byB1c2UgQ29NSSBhcyBtdWNoIG1vcmUgdGhhbiBh IHJlcGxhY2VtZW50IGZvciBSRVNUQ29uZiBpbiBjb25zdHJhaW5lZCBuZXR3b3JrLiBJbiB0aGUg Q29NSSBkcmFmdCwgeW91IG1ha2UgYSBwb2ludA0KIG9mIGNvbXBhcmluZyBDb01JIHRvIExXTTJN IGFuZCBwb2ludCBvdXQgdGhlIGFkdmFudGFnZXMuIEFzIGZhciBhcyBJIGFtIGF3YXJlLCBMV00y TSBoYXMgbm90aGluZyB0byBkbyB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQvb3IgcmVzdGNv bmYuIExXTTJNIGlzIHVzZWQgdG8gcmVhbGx5IG1hbmFnZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFu ZCBhcHBsaWNhdGlvbnMgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIHVzZS4gU28sIHRoaXMgY29t cGFyaXNpb24NCiBvZiBDb01JIHdpdGggTFdNMk0gaXMgdmVyeSBtaXNsZWFkaW5nLiBJIHBlcnNv bmFsbHkgd2FudCB0byB1c2UgQ29NSS9Db09MIHRvIHJlcGxhY2UgaW5zdGVhZCBvZiBMV00yTSBh bmQgSSBzZWUgZ3JlYXQgYmVuZWZpdHMgaW4gZG9pbmcgc28uIExpa2UgaXQgb3Igbm90LCBZQU5H IGxvb2tzIGxpa2UgYSBkYXRhIG1vZGVsbGluZyB0b29sIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHNl dmVyYWwgZGlmZmVyZW50IHB1cnBvc2VzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk1heWJlIHdlIGNhbiBidWlsZCAyIHNlcGFyYXRlIHByb3RvY29s cyBvdXQgdGhlIHBhcnRzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMzc2MDkyO21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMzNzYwOTI7bXNvLXN0 eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj5bQVNdIE1heWJlIHRoaXMgbWFrZXMgc2Vu c2UgYnV0IHdlIHNob3VsZCB0cnkgdG8gbWVyZ2UgdGhlIHR3byBpZiBwb3NzaWJsZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ QWJvdXQg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBkb24ndCBzZWUgbWFu YWdlZCBJRHMgYXMgYSBnZW5lcmFsIHNvbHV0aW9uLCBidXQgSU1PIGNvbnN0cmFpbmVkIG5vZGVz 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMzNzYwOTI7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzM3NjA5Mjtt c28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPltBU10gSSBwYXJ0bHkgYWdyZWUg YWJvdXQgdGhpcyBhc3Nlc3NtZW50LiBJIHRoaW5rIHRoYXQgaGF2aW5nIGEgY2VudHJhbCByZWdp c3RyeSBmb3IgYWxsIG1hbmFnZWQgSURzIGlzIGluZGVlZCB1bnJlYWxpc3RpYyBhbmQgd2lsbA0K IG5vdCB3b3JrIGluIHRoZSBsb25nIHJ1bi4gSG93ZXZlciwgSSBzZWUgdGhhdCBDb01JL0NvT0ws IGlmIHVzZWQgZm9yIGFwcGxpY2F0aW9uIG1hbmFnZW1lbnQsIHdpbGwgYmUgYSB0b29sIHRoYXQg b3RoZXIgU0RPcyBzdWNoIGFzIE9NQSBvciBJUFNPIGNhbiByZXVzZS4gSSBleHBlY3QgdGhhdCBp ZiB3ZSBwcm92aWRlIHN0YW5kYXJkIG1ldGhvZHMgZm9yIGFuIFNETyAoZS5nLiB1c2UgcmVzb3Vy Y2UgdHlwZSB0byBpbmRpY2F0ZSB0aGUgdHlwZQ0KIG9mIFlBTkcgbW9kdWxlKSB0aGVuIHRoZXNl IFNET3MgY2FuIG1hbmFnZSBJRHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8gdGhlIFNETy4gPG86cD4N CjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWJvdXQg4oCcYnV0IElNTyBjb25zdHJhaW5l ZCBub2RlcyB3aWxsIG5ldmVyIGJlIHVzaW5nIHRoZSBzYW1lIG1vZHVsZXMgdGhhdCBhcmUgd3Jp dHRlbiBmb3IgbmV0d29ya2luZyBlcXVpcG1lbnQu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz NzYwOTI7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzM3NjA5Mjttc28tc3R5bGUtdGV4 dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPltBU10gTWF5YmUgY29uc3RyYWluZWQgbm9kZXMgd2ls bCBub3QgdXNlIGFsbCB0aGUgbW9kdWxlcyB3cml0dGVuIGZvciBuZXR3b3JraW5nDQogZXF1aXBt ZW50LiBIb3dldmVyLCBJIGFtIHN1cmUgc29tZSBvZiB0aGVtIGNvdWxkIGJlIGFuZCB3aWxsIGJl IHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkFib3V0IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldl IHBsYW4gdG8ganVzdCB1c2UgTkFDTSB0byBjb25maWd1cmUgd2hhdCBhIGNsaWVudCBpcyBhdXRo b3JpemVkIHRvIGFjY2VzcyB3cnQvIG1hbmFnZW1lbnQgZGF0YSBhbmQgb3BlcmF0aW9ucy4mbmJz cDsgQWdhaW4sDQogaG93IG11Y2ggdmFsdWUgaXMgdGhlcmUgaW4gcmVpbnZlbnRpbmcgc3R1ZmY/ 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMzNzYwOTI7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtY29sb3I6IzM3NjA5Mjtt c28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUiPltBU10gSSBhbSBub3Qgc2F5aW5n IHRoYXQgTkFDTSBzaG91bGQgbm90IGJlIHVzZWQuIEkgYW0ganVzdCBzYXlpbmcgdGhhdCB3ZSBz aG91bGQgdGhpbmsgYWJvdXQgaXQgYW5kIGlmIE5BQ00gd29ya3MgYXMgaXQgaXMgdGhlbiBzdXJl DQogd2UgY2FuIHJldXNlIGl0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWJv dXQg4oCcVGhpcyBkZXNjcmliZXMgd2hhdCBpcyBhbGxvd2VkIHRvIGNoYW5nZSBpbiBhIG5ldyBy ZXZpc2lvbiBvZiBhIG1vZHVsZS4gTm90aWNlIGhvdyAmcXVvdDtyZW5hbWUgb2JqZWN0JnF1b3Q7 IGlzIG5vdCBpbiB0aGUgbGlzdD/igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzM3NjA5Mjttc28tc3R5bGUtdGV4dGZpbGwt ZmlsbC1jb2xvcjojMzc2MDkyO21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+ W0FTXSBUaGUgY29vbCBtb2R1bGUgaWRlbnRpZmllciBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMg dGhlIG5hbWUgb2YgdGhlIFlBTkcgbW9kdWxlLiBJdCBpcyBhbiBleHRlbnNpb24gYW5kIHRoZXJl IGFyZSBubyBydWxlcyBhcyBmYXINCiBhcyBJIGtub3cgaW4gWUFORyB0aGF0IHNheXMgdGhpcyBj YW5ub3QgY2hhbmdlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QWJvdXQg4oCc U3RhYmxlIGlkZW50aWZpZXJzIGFyZSB1c2VmdWwgYmVjYXVzZSBvbGQgY2xpZW50cyBjYW4gY29u dGludWUgdG8gd29yayB3aXRoIG5ldyBzZXJ2ZXJzLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzc2MDkyO21zby1zdHls ZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMzNzYwOTI7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxw aGE6MTAwLjAlIj5bQVNdIE9rYXksIEkgY2FuIGxpdmUgd2l0aCB0aGlzIGV4cGxhbmF0aW9uLiBN YXliZSB3ZSBjYW4gdGhpbmsgb2YgYXV0b21hdGVkIG51bWJlcmluZyBzY2hlbWVzIHdoZXJlIGRh dGEgbm9kZXMgaW4gbmV3ZXIgdmVyc2lvbnMgYXJlDQogYXV0b21hdGljYWxseSBhc3NpZ25lZCBJ RHMgaGlnaGVyIHRoYW4gYWxsIHByZXZpb3VzIHZlcnNpb25zIGluIHRoZSBtb2R1bGUuIDxvOnA+ DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVt YXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmVpdGFnLCAyMC4gTm92ZW1iZXIgMjAx NSAwMDowNjxicj4NCjxiPlRvOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uPGJyPg0KPGI+Q2M6PC9iPiBT b21hcmFqdSBBYmhpbmF2OyBDb3JlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gQ29N SSBDb29sIGRyYWZ0IHNwbGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92 IDE5LCAyMDE1IGF0IDg6MzcgQU0sIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNhYm9AdHppLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keSBCaWVybWFuIHdyb3Rl Ojxicj4NCiZndDsgSSB0aGluayB0aGUgdGVybSAmcXVvdDtjb25zdHJhaW5lZCZxdW90OyBpcyBu b3Qgd2lkZWx5IGFncmVlZCB1cG9uIGluIHRoZSBJRVRGLjxicj4NCjxicj4NCk5vLiZuYnNwOyBC dXQgd2UgYXJlIHVzaW5nIGl0IGluIHRoZSBzZW5zZSBvZiBSRkMgNzIyOCBoZXJlLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0suIFNvIHRoYXQgbWVhbnMg dGhlIHNjb3BlIGluY2x1ZGVzIGNvbnN0cmFpbmVkIG5ldHdvcmtzLCBub3QganVzdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29uc3RyYWluZWQg bm9kZXMuIEkgYW0gaW50ZXJlc3RlZCBpbiB1c2luZyBDb01JIGFzIGEgcmVwbGFjZW1lbnQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBSRVNU Q09ORiBpbiBjb25zdHJhaW5lZCBuZXR3b3JrcyB3aGVyZSBUQ1AgZG9lc24ndCByZWFsbHkgd29y ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB3YW50IHRvIHVzZSB0aGUgc2FtZSAmcXVvdDtjb250ZW50IGxheWVyJnF1b3Q7IGFuZCBjb2Rl IGZvciB0aGF0IGNvbnRlbnQgYWNyb3NzIHRoZSBib2FyZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgbWVhbnMgdGhlIGV4YWN0IHNhbWUg WUFORyBkYXRhIG1vZGVscywgd2l0aG91dCBleGNlcHRpb24sIGFuZCB0aGUgdHJhbnNsYXRpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyb20g UkVTVENPTkYgZmVhdHVyZXMgdG8gQ29NSSBmZWF0dXJlcyBtdXN0IGJlIGxvc3MtbGVzcy4mbmJz cDsgVGhlIHByb3RvY29sLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+bWVzc2FnaW5nLCBhbmQgdHJhbnNwb3J0IGxheWVycyBjYW4gYWxsIGNoYW5n ZSBhcyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgcmVhbGl6ZSB0aGlzIGlzIG5vdCB3aGF0IG1pZ2h0IHdvcmsgYmVzdCBmb3Ig YSBjb25zdHJhaW5lZCBub2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWF5YmUgd2UgY2FuIGJ1aWxkIDIgc2VwYXJhdGUgcHJvdG9jb2xzIG91 dCB0aGUgcGFydHMgdGhhdCBoYXZlIGJlZW4gcHJvcG9zZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHNlZSBtYW5hZ2VkIElEcyBh cyBhIGdlbmVyYWwgc29sdXRpb24sIGJ1dCBJTU8gY29uc3RyYWluZWQgbm9kZXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpbGwgbmV2ZXIgYmUg dXNpbmcgdGhlIHNhbWUgbW9kdWxlcyB0aGF0IGFyZSB3cml0dGVuIGZvciBuZXR3b3JraW5nIGVx dWlwbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpHcsO8w59lLCBDYXJzdGVuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIFRoZSBjb250ZW50cyBvZiB0aGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVk IHJlY2lwaWVudC4gVGhleSBtYXkgbm90IGJlIGRpc2Nsb3NlZCB0byBvciB1c2VkIGJ5IG9yIGNv cGllZCBpbiBhbnkgd2F5IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGll bnQuIElmDQogdGhpcyBlLW1haWwgaXMgcmVjZWl2ZWQgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlh dGVseSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBlLW1haWwgYW5kIGF0dGFjaGVk IGRvY3VtZW50cy4gUGxlYXNlIG5vdGUgdGhhdCBuZWl0aGVyIHRoZSBzZW5kZXIgbm9yIHRoZSBz ZW5kZXIncyBjb21wYW55IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9yIHZpcnVzZXMgYW5k IGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBvcg0KIG90aGVyd2lzZSBjaGVjayB0 aGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzLg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0E9A48AB39AF3547ACD28A6DE3E2906A0F1AD509ATBRAGMSX02itis_-- From nobody Fri Nov 20 04:22:40 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733061B2F50 for ; Fri, 20 Nov 2015 04:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.585] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKG_Rt5f3QbA for ; Fri, 20 Nov 2015 04:22:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828751B2F3C for ; Fri, 20 Nov 2015 04:22:37 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:45ad:c3e9:4731:d337] (unknown [IPv6:2a01:5e0:29:ffff:45ad:c3e9:4731:d337]) by mail.nic.cz (Postfix) with ESMTPSA id 04A15181B2A; Fri, 20 Nov 2015 13:22:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1448022156; bh=l4i1T7das1B0zgmCMUsbJ8PT0h11OZwj69M/i4EjUoA=; h=From:Date:To; b=UphTw5++dVgKVuXVHUBYbi2R23JOauxiWw8l576hdtPqrQASmj9yp8uKC1xuAf+w9 WKOiXsIYV6yi2mdIrHdGZmPmkk9r3NEcEhTqxFVC4SmAhcIQ+6aEPu4di1CIYZBGr0 1eoPoNqi2yFZtNJ6OniREBRRw8gaSUzQnMdmNvRw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Ladislav Lhotka In-Reply-To: <20151119152734.GA3518@elstar.local> Date: Fri, 20 Nov 2015 13:22:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4595D109-2EBC-4176-A65E-D4B075DD6CF0@nic.cz> References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> <564DE2C1.50205@tzi.org> <20151119152734.GA3518@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3096.5) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 12:22:39 -0000 > On 19 Nov 2015, at 16:27, Juergen Schoenwaelder = wrote: >=20 > On Thu, Nov 19, 2015 at 03:54:57PM +0100, Carsten Bormann wrote: >>=20 >> So I think that Peter's reminder to stay close to >> draft-ietf-netmod-yang-json -- unless we do need to deviate -- is = quite >> germane. >>=20 >=20 > I do not understand what "stay close to draft-ietf-netmod-yang-json" > means. I think this requires an explanation. >=20 > To give you an example: draft-ietf-netmod-yang-json is following > I-JSON rules and one of them says that I-JSON numbers are limited in > precision. As a consequence, 64-bit numbers are I-JSON encoded as > strings for I-JSON compliance. I think CBOR does not require this > since it does not have this particular restriction. So do we now > continue to do this even though CBOR does not suffer from I-JSON > limitations? >=20 > I think my preference would be a clean mapping YANG to CBOR and not a > mapping YANG to I-JSON to CBOR that carries I-JSON restrictions over > to CBOR. The simple reason is that the longer the transformation > chain, the more arcane rules you accumulate. I agree, it isn't probably necessary to couple the CBOR mapping with = JSON as defined in the yang-json draft. Some of the I-JSON restrictions = are an ugly compromise, really, and you'd better avoid them. I believe a = mapping between CBOR, JSON and XML encodings will be possible anyway. Lada >=20 > But then the CBOR spec has already JSON to CBOR translation rules so > YANG to I-JSON to CBOR is already defined somehow. Someone needs to > compile a list of cases where YANG to CBOR would be different from > YANG to JSON to CBOR before we can take an informed decision. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Nov 20 05:13:44 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716AC1A89F5 for ; Fri, 20 Nov 2015 05:13:42 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCQPjP_xnIkR for ; Fri, 20 Nov 2015 05:13:40 -0800 (PST) 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 0F3D01A892F for ; Fri, 20 Nov 2015 05:13:40 -0800 (PST) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 635ACA80F1; Fri, 20 Nov 2015 14:13:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MdExUAjlyDnb; Fri, 20 Nov 2015 14:13:36 +0100 (CET) X-Originating-IP: 91.61.0.39 Received: from nar.fritz.box (p5B3D0027.dip0.t-ipconnect.de [91.61.0.39]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 0B36AA80D9; Fri, 20 Nov 2015 14:13:35 +0100 (CET) Message-ID: <564F1C7E.5090904@tzi.org> Date: Fri, 20 Nov 2015 14:13:34 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Ladislav Lhotka References: <02d2efc9e66b090dd7b7932ae4e749cd@xs4all.nl> <564DE2C1.50205@tzi.org> <20151119152734.GA3518@elstar.local> <4595D109-2EBC-4176-A65E-D4B075DD6CF0@nic.cz> In-Reply-To: <4595D109-2EBC-4176-A65E-D4B075DD6CF0@nic.cz> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Core Subject: Re: [core] YANG to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 13:13:42 -0000 Ladislav Lhotka wrote: >> On 19 Nov 2015, at 16:27, Juergen Schoenwaelder wrote: >> >> On Thu, Nov 19, 2015 at 03:54:57PM +0100, Carsten Bormann wrote: >>> So I think that Peter's reminder to stay close to >>> draft-ietf-netmod-yang-json -- unless we do need to deviate -- is quite >>> germane. >>> >> I do not understand what "stay close to draft-ietf-netmod-yang-json" >> means. I think this requires an explanation. "-- unless we do need to deviate --" >> To give you an example: draft-ietf-netmod-yang-json is following >> I-JSON rules and one of them says that I-JSON numbers are limited in >> precision. As a consequence, 64-bit numbers are I-JSON encoded as >> strings for I-JSON compliance. I think CBOR does not require this >> since it does not have this particular restriction. So do we now >> continue to do this even though CBOR does not suffer from I-JSON >> limitations? No. Here we clearly need to deviate to reduce unnecessary complexity. >> I think my preference would be a clean mapping YANG to CBOR and not a >> mapping YANG to I-JSON to CBOR that carries I-JSON restrictions over >> to CBOR. The simple reason is that the longer the transformation >> chain, the more arcane rules you accumulate. I completely agree. What I was trying to say was that the two mappings should stay close, at least where the mappings can reasonably use the common data model of JSON and CBOR. The one place where we probably will have additional divergence is the area of identifiers/selectors, where for COMI the CBOR mapping will need to provide more flexibility. Can we decouple this aspect from the other elements of the YANG-CBOR mapping? I hope so, but we haven't demonstrated that yet. > I agree, it isn't probably necessary to couple the CBOR mapping with JSON as defined in the yang-json draft. Some of the I-JSON restrictions are an ugly compromise, really, and you'd better avoid them. I believe a mapping between CBOR, JSON and XML encodings will be possible anyway. > > Lada > >> But then the CBOR spec has already JSON to CBOR translation rules so >> YANG to I-JSON to CBOR is already defined somehow. ... and the result of this two-step process might be useful as a "default" mapping, which we use unless there is a reason to deviate. >> Someone needs to >> compile a list of cases where YANG to CBOR would be different from >> YANG to JSON to CBOR before we can take an informed decision. Indeed, and this is work that needs to be done very soon. Do we need to build a formal design team for this work around the extraction of the YANG-to-CBOR mapping from the COMI (and COOL) documents? Gr眉脽e, Carsten From nobody Fri Nov 20 09:36:53 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32631B3A09 for ; Fri, 20 Nov 2015 09:36:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4548RUJqs_0 for ; Fri, 20 Nov 2015 09:36:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7ED91B3A08 for ; Fri, 20 Nov 2015 09:36:47 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB422.namprd04.prod.outlook.com (10.141.58.150) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 17:36:46 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 17:36:46 +0000 From: Rodney Cummings To: Carsten Bormann , Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwteQFUWYBvd0yDLSdmSQn7rZ6gWGHwgAAhdwCAAOkigIAAEbUAgACGqICAASZkgIAAaEQAgAAFAoCAAGyNAIAAfaIAgAC0CsA= Date: Fri, 20 Nov 2015 17:36:45 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@tzi.org> <564EBF4A.8010405@tzi.org> In-Reply-To: <564EBF4A.8010405@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.95] x-microsoft-exchange-diagnostics: 1; BN1PR04MB422; 5:yrYOyNhcnV/rKeEt7MCGZo8CPEkMg6/MhbDsqPwgbJUnxBbCXjXL3vmgjfY2MS/xwftAl5aaA0FJ5/XPNKLcUgAjtchuuRahXBVojoKpZYLaDlPO0AzqxakaJrLBmSpAmJjQNaXfUW71+Oyq3dHMGA==; 24:X7L8NfVCrMHBq2x8TEW+p7ijrQznDOyVqrrB/PPhFdNbMAIb5FmHvWUNgNxeofhIyom+ix8qr2FjKJR+EWDn8nrPXAruqZb9kwq1Hvs+5jw=; 20:81rmtjj42HFS95qr/BK3jmgfPvG9GZT7fyMycxwca6yMqZsUHVcm4blv04zjPLh1RC+ReDiTmIdndHE3ZC187Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB422; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN1PR04MB422; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB422; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(189002)(199003)(76176999)(106356001)(87936001)(101416001)(5004730100002)(50986999)(5002640100001)(5007970100001)(10400500002)(189998001)(5001960100002)(5003600100002)(74316001)(105586002)(5008740100001)(11100500001)(33656002)(15975445007)(2950100001)(99286002)(92566002)(106116001)(81156007)(54356999)(122556002)(2900100001)(93886004)(97736004)(40100003)(76576001)(66066001)(86362001)(586003)(3846002)(19580405001)(19580395003)(5001770100001)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB422; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 17:36:45.8925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB422 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 17:36:51 -0000 SSBhZ3JlZSB3aXRoIENhcnN0ZW4gb24gdGhlIHBvaW50IGJlbG93Lg0KDQpBcyBhbiBleGFtcGxl LCB0aGUgWUFORyBkZXZlbG9wbWVudCBpbiBwcm9ncmVzcyBmb3IgODAyLjFRIGlzIHVzaW5nIGZl YXR1cmVzLCBhdWdtZW50cywgYW5kIHNvIG9uIGluIG9yZGVyIHRvIGJ1aWxkIHVwIG1vZHVsZXMg ZnJvbSB0aGUgYmFzaWMgY29tcG9uZW50cyB0byBtb3JlIGNvbXBsZXggY29tcG9uZW50cyAoZS5n LiBmb3IgcHJvdmlkZXJzKS4gVGhlIGJhc2ljIGNvbXBvbmVudHMgZXNzZW50aWFsbHkgcmVwcmVz ZW50IHRoZSBoYXJkd2FyZSByZWdpc3RlcnMgb2YgYSBzd2l0Y2guIEFzIGNvbnN0cmFpbmVkIHBy b2R1Y3RzIGV4cGxvcmUgaW50ZWdyYXRpb24gb2YgYW4gODAyLjFRIHN3aXRjaCBpbiB0aGVpciBw cm9kdWN0LCB0aGUgcXVlc3Rpb24gb2YgYSBjb25zdHJhaW5lZCBuZXR3b3JrIG1hbmFnZW1lbnQg cHJvdG9jb2wgY29tZXMgdXAuIElNTyBDb01JL0NvT0wgcHJvdmlkZXMgYW4gZXhjZWxsZW50IHNv bHV0aW9uIGZvciB0aGlzIHVzZSBjYXNlLCB1c2luZyB0aGUgODAyLjFRIG1vZHVsZShzKSBmb3Ig YmFzaWMgY29tcG9uZW50cyAoaS5lLiBtb2R1bGVzIG5vdCBzcGVjaWZpY2FsbHkgdGFyZ2V0ZWQg dG8gY29uc3RyYWluZWQpLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0 ZW4gQm9ybWFubg0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDIwLCAyMDE1IDEyOjM2IEFNDQo+ IFRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gQ2M6IENvcmUgPGNvcmVA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbY29yZV0gQ29NSSBDb29sIGRyYWZ0IHNwbGl0cw0K PiANCj4gQW5keSBCaWVybWFuIHdyb3RlOg0KPiA+IFsuLi5dIElNTyBjb25zdHJhaW5lZCBub2Rl cw0KPiA+IHdpbGwgbmV2ZXIgYmUgdXNpbmcgdGhlIHNhbWUgbW9kdWxlcyB0aGF0IGFyZSB3cml0 dGVuIGZvciBuZXR3b3JraW5nDQo+ID4gZXF1aXBtZW50Lg0KPiANCj4gSXMgdGhhdCBzbz8gIFdo eSB3b3VsZG4ndCBJIHVzZSBhIGNvdXBsZSBvZiBpdGVtcyBmcm9tLCBzYXksIFJGQyA3MzE3DQo+ IChvciA3Mjc3KSBpbiBteSBjb25zdHJhaW5lZCBub2RlPyAgSW4gdGhlIGVuZCB0aGVzZSBhcmUg anVzdCByZXNvdXJjZXMNCj4gdGhhdCBJIGFkZCB0byBteSByZXNvdXJjZSB0cmVlLiAgT2YgY291 cnNlLCBjaGVycnktcGlja2luZyBtYXkgcmVxdWlyZQ0KPiBzb21lIGZvcm0gb2Ygc3Vic2V0dGlu ZyB0aGF0IG1heSBub3QgeWV0IGJlIHBhcnQgb2YgdGhlIE5FVENPTkYgYXBwcm9hY2guDQo+IA0K PiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3JlQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From nobody Fri Nov 20 09:49:05 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7F1B3A5F for ; Fri, 20 Nov 2015 09:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PSUt7u_Tofl for ; Fri, 20 Nov 2015 09:49:03 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078DF1B3A5E for ; Fri, 20 Nov 2015 09:49:03 -0800 (PST) Received: by lbblt2 with SMTP id lt2so66450509lbb.3 for ; Fri, 20 Nov 2015 09:49:01 -0800 (PST) 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:content-type; bh=mH2uY//xIg4K/o7eyEhen6J/eZivs+GBS+Lt+gaeAGU=; b=n5dt/TEEAIdz0vO6mQEZhPYKIZzenxqLQMcubJjO8X3Kh5bnHO9sso1bTo7GiHBUN+ lKuG+zWrjM2t/E1lgOFkz5E0+TKwvFkey54Wdb5+m+Br6pIWFmbW1N0iHVH5PabwkHH7 JSyhfe/FPG2Na6VwZ0Xt9MQkONUT/mgMRhdXBJ4NhjMbzcBPyDffMNPJlu84Y0SRGn3m 1eypv+xX2HpeMqXUyTU6Lv60NvMqdUTMt4pFbd0K3NEFRqRu3RQ+BWvm5JTJUvw180Bj kpEFvVRCdbZzb1kEBQv+Yv9bj/E3WA9FLfNht2HovwbLwhyz5lQFJD0cV5qrJ07T96S/ PkYw== 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:content-type; bh=mH2uY//xIg4K/o7eyEhen6J/eZivs+GBS+Lt+gaeAGU=; b=CvjN+HDAwJQKhM2jTOLk/8kw1acVlwnb610KC4bifHseQ+GqQv4qigjfMgYnioGNAw 4bLwNqsZTJJmRpi2cyxFQSIwXw3jhduJNcwOD/0mkkFrzljSn08Ff7ggZ8UdQW3rCZJP xwTzHoyJWncVyzHQ8PG67rt7mWzw1t3Y5jgkfFF3apk5RGN4bowpJOIu7aq+X8ELcVa8 gOVyWlIZcYgz1SA5crLNNwQ8MqPdC/qhd780+eP6TCIA4FmZsiHHEQAFhw1LADxjWjm9 cx7+zFUfcANH/ODUXJiQnmKD5Ym0FAGuXXHiXFjyPYvKe5tVRGzFgTAU2uy6q51OQyvh DuWw== X-Gm-Message-State: ALoCoQmu/95Yk450ClBeLi58AIJBN34CRch+BsZeFQ1uSCulEmRoY69WECPeFYBFsoO6Rgap4jpl MIME-Version: 1.0 X-Received: by 10.112.202.101 with SMTP id kh5mr6433542lbc.66.1448041741064; Fri, 20 Nov 2015 09:49:01 -0800 (PST) Received: by 10.112.144.106 with HTTP; Fri, 20 Nov 2015 09:49:00 -0800 (PST) In-Reply-To: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@tzi.org> <564EBF4A.8010405@tzi.org> Date: Fri, 20 Nov 2015 09:49:00 -0800 Message-ID: From: Andy Bierman To: Rodney Cummings Content-Type: multipart/alternative; boundary=001a11c3724c98b44f0524fc7da7 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 17:49:05 -0000 --001a11c3724c98b44f0524fc7da7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think it will a challenge for the CORE WG to get IANA to manage the manual number assignment of even IETF modules, let alone all YANG modules from all vendors and all other SDOs. The cost of even 1 mistak= e is rather high (like a wrong port assignment). YANG Hash will allow any YANG module that has ever been written or ever could be written to be used without modification or manual number assignment. I completely agree with you about CoMI, but not CoOL. Andy On Fri, Nov 20, 2015 at 9:36 AM, Rodney Cummings wrote: > I agree with Carsten on the point below. > > As an example, the YANG development in progress for 802.1Q is using > features, augments, and so on in order to build up modules from the basic > components to more complex components (e.g. for providers). The basic > components essentially represent the hardware registers of a switch. As > constrained products explore integration of an 802.1Q switch in their > product, the question of a constrained network management protocol comes > up. IMO CoMI/CoOL provides an excellent solution for this use case, using > the 802.1Q module(s) for basic components (i.e. modules not specifically > targeted to constrained). > > > > -----Original Message----- > > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > > Sent: Friday, November 20, 2015 12:36 AM > > To: Andy Bierman > > Cc: Core > > Subject: Re: [core] CoMI Cool draft splits > > > > Andy Bierman wrote: > > > [...] IMO constrained nodes > > > will never be using the same modules that are written for networking > > > equipment. > > > > Is that so? Why wouldn't I use a couple of items from, say, RFC 7317 > > (or 7277) in my constrained node? In the end these are just resources > > that I add to my resource tree. Of course, cherry-picking may require > > some form of subsetting that may not yet be part of the NETCONF approac= h. > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > --001a11c3724c98b44f0524fc7da7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think it will a challenge for the= CORE WG to get IANA to manage
the manual number assignment of ev= en IETF modules, let alone all
YANG modules from all vendors and = all other SDOs. The cost of even 1 mistake
is rather high (like a= wrong port assignment).

YANG Hash will allow any = YANG module that has ever been written
or ever could be written t= o be used without modification or manual
number assignment.
=

I completely agree with you about CoMI, but not CoOL.


Andy


On Fri, Nov 20, 2015 at= 9:36 AM, Rodney Cummings <rodney.cummings@ni.com> wrot= e:
I agree with Carsten on the point belo= w.

As an example, the YANG development in progress for 802.1Q is using feature= s, augments, and so on in order to build up modules from the basic componen= ts to more complex components (e.g. for providers). The basic components es= sentially represent the hardware registers of a switch. As constrained prod= ucts explore integration of an 802.1Q switch in their product, the question= of a constrained network management protocol comes up. IMO CoMI/CoOL provi= des an excellent solution for this use case, using the 802.1Q module(s) for= basic components (i.e. modules not specifically targeted to constrained).<= br>

> -----Original Message-----
> From: core [mailto:core-bounc= es@ietf.org] On Behalf Of Carsten Bormann
> Sent: Friday, November 20, 2015 12:36 AM
> To: Andy Bierman <andy@yumawo= rks.com>
> Cc: Core <core@ietf.org> > Subject: Re: [core] CoMI Cool draft splits
>
> Andy Bierman wrote:
> > [...] IMO constrained nodes
> > will never be using the same modules that are written for network= ing
> > equipment.
>
> Is that so?=C2=A0 Why wouldn't I use a couple of items from, say, = RFC 7317
> (or 7277) in my constrained node?=C2=A0 In the end these are just reso= urces
> that I add to my resource tree.=C2=A0 Of course, cherry-picking may re= quire
> some form of subsetting that may not yet be part of the NETCONF approa= ch.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--001a11c3724c98b44f0524fc7da7-- From nobody Fri Nov 20 10:04:06 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D568E1B3B07 for ; Fri, 20 Nov 2015 10:04:04 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkUJ3fH98imK for ; Fri, 20 Nov 2015 10:04:00 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4120A1B3ACD for ; Fri, 20 Nov 2015 10:04:00 -0800 (PST) Received: from BN1PR04MB424.namprd04.prod.outlook.com (10.141.58.153) by BN1PR04MB422.namprd04.prod.outlook.com (10.141.58.150) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 18:03:57 +0000 Received: from BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) by BN1PR04MB424.namprd04.prod.outlook.com ([169.254.6.133]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 18:03:57 +0000 From: Rodney Cummings To: Andy Bierman Thread-Topic: [core] CoMI Cool draft splits Thread-Index: AQHRIRwteQFUWYBvd0yDLSdmSQn7rZ6gWGHwgAAhdwCAAOkigIAAEbUAgACGqICAASZkgIAAaEQAgAAFAoCAAGyNAIAAfaIAgAC0CsCAAAgGAIAAA+4Q Date: Fri, 20 Nov 2015 18:03:57 +0000 Message-ID: References: <0559fa310f26530d1c1e89c1ed64b7aa@xs4all.nl> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1AC492@ATBRAGMSX02.itiso.net> <0E9A48AB39AF3547ACD28A6DE3E2906A0F1ACE72@ATBRAGMSX02.itiso.net> <564DFAD7.1000800@tzi.org> <564EBF4A.8010405@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rodney.cummings@ni.com; x-originating-ip: [130.164.62.95] x-microsoft-exchange-diagnostics: 1; BN1PR04MB422; 5:fjrZqh7dE/6xmCz8tsYW/6+1qSSXNsm/Z9/3pKMQY8DM0BXN2V1kv2sC2cv9fOAv8HFnLv/Yc0sMFoMJtOnSLdcpTQFTvlD8a4wJCKu9kdvyIrwj4nCS4e+IxhIWpAP5ePt1L+PUWqsvEiT16we1eA==; 24:d+E7zqsCZGbypwXgvLe2h8eZTdbsCXSFFsxd6xUJeJUaRlgm6jvCORGkb7UTU8AOYcid4fvS+exCfFKRBq3ZP0tRUOYK2jPNhkkV3dVwCvI=; 20:21n6gcJ6aadBY+Q7Bcv5BqZHmH/olyaujGWttdwogR84MvspCOML23Ku6dgdVQPrPzoYMj4vMF7VnnyKO4A4rQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB422; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN1PR04MB422; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB422; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(377454003)(189002)(199003)(19625215002)(76176999)(106356001)(87936001)(101416001)(5004730100002)(5002640100001)(50986999)(5007970100001)(10400500002)(5001960100002)(110136002)(5003600100002)(189998001)(74316001)(105586002)(5008740100001)(11100500001)(33656002)(16236675004)(15975445007)(2950100001)(99286002)(92566002)(106116001)(81156007)(54356999)(122556002)(790700001)(2900100001)(93886004)(97736004)(40100003)(76576001)(66066001)(86362001)(586003)(3846002)(19580405001)(19580395003)(19617315012)(19300405004)(6116002)(102836003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB422; H:BN1PR04MB424.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ni.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR04MB424B77225FB5E0BFBD088CF921A0BN1PR04MB424namprd_" MIME-Version: 1.0 X-OriginatorOrg: ni.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 18:03:57.6227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB422 Archived-At: Cc: Core Subject: Re: [core] CoMI Cool draft splits X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 18:04:05 -0000 --_000_BN1PR04MB424B77225FB5E0BFBD088CF921A0BN1PR04MB424namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoZSBDb01JIGFwcHJvYWNoIGlzIGJldHRlciBpbiB0aGlzIHJlc3BlY3Qu DQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpTZW50OiBG cmlkYXksIE5vdmVtYmVyIDIwLCAyMDE1IDExOjQ5IEFNDQpUbzogUm9kbmV5IEN1bW1pbmdzIDxy b2RuZXkuY3VtbWluZ3NAbmkuY29tPg0KQ2M6IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3Jn PjsgQ29yZSA8Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0gQ29NSSBDb29sIGRy YWZ0IHNwbGl0cw0KDQpIaSwNCg0KSSB0aGluayBpdCB3aWxsIGEgY2hhbGxlbmdlIGZvciB0aGUg Q09SRSBXRyB0byBnZXQgSUFOQSB0byBtYW5hZ2UNCnRoZSBtYW51YWwgbnVtYmVyIGFzc2lnbm1l bnQgb2YgZXZlbiBJRVRGIG1vZHVsZXMsIGxldCBhbG9uZSBhbGwNCllBTkcgbW9kdWxlcyBmcm9t IGFsbCB2ZW5kb3JzIGFuZCBhbGwgb3RoZXIgU0RPcy4gVGhlIGNvc3Qgb2YgZXZlbiAxIG1pc3Rh a2UNCmlzIHJhdGhlciBoaWdoIChsaWtlIGEgd3JvbmcgcG9ydCBhc3NpZ25tZW50KS4NCg0KWUFO RyBIYXNoIHdpbGwgYWxsb3cgYW55IFlBTkcgbW9kdWxlIHRoYXQgaGFzIGV2ZXIgYmVlbiB3cml0 dGVuDQpvciBldmVyIGNvdWxkIGJlIHdyaXR0ZW4gdG8gYmUgdXNlZCB3aXRob3V0IG1vZGlmaWNh dGlvbiBvciBtYW51YWwNCm51bWJlciBhc3NpZ25tZW50Lg0KDQpJIGNvbXBsZXRlbHkgYWdyZWUg d2l0aCB5b3UgYWJvdXQgQ29NSSwgYnV0IG5vdCBDb09MLg0KDQoNCkFuZHkNCg0KDQpPbiBGcmks IE5vdiAyMCwgMjAxNSBhdCA5OjM2IEFNLCBSb2RuZXkgQ3VtbWluZ3MgPHJvZG5leS5jdW1taW5n c0BuaS5jb208bWFpbHRvOnJvZG5leS5jdW1taW5nc0BuaS5jb20+PiB3cm90ZToNCkkgYWdyZWUg d2l0aCBDYXJzdGVuIG9uIHRoZSBwb2ludCBiZWxvdy4NCg0KQXMgYW4gZXhhbXBsZSwgdGhlIFlB TkcgZGV2ZWxvcG1lbnQgaW4gcHJvZ3Jlc3MgZm9yIDgwMi4xUSBpcyB1c2luZyBmZWF0dXJlcywg YXVnbWVudHMsIGFuZCBzbyBvbiBpbiBvcmRlciB0byBidWlsZCB1cCBtb2R1bGVzIGZyb20gdGhl IGJhc2ljIGNvbXBvbmVudHMgdG8gbW9yZSBjb21wbGV4IGNvbXBvbmVudHMgKGUuZy4gZm9yIHBy b3ZpZGVycykuIFRoZSBiYXNpYyBjb21wb25lbnRzIGVzc2VudGlhbGx5IHJlcHJlc2VudCB0aGUg aGFyZHdhcmUgcmVnaXN0ZXJzIG9mIGEgc3dpdGNoLiBBcyBjb25zdHJhaW5lZCBwcm9kdWN0cyBl eHBsb3JlIGludGVncmF0aW9uIG9mIGFuIDgwMi4xUSBzd2l0Y2ggaW4gdGhlaXIgcHJvZHVjdCwg dGhlIHF1ZXN0aW9uIG9mIGEgY29uc3RyYWluZWQgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29s IGNvbWVzIHVwLiBJTU8gQ29NSS9Db09MIHByb3ZpZGVzIGFuIGV4Y2VsbGVudCBzb2x1dGlvbiBm b3IgdGhpcyB1c2UgY2FzZSwgdXNpbmcgdGhlIDgwMi4xUSBtb2R1bGUocykgZm9yIGJhc2ljIGNv bXBvbmVudHMgKGkuZS4gbW9kdWxlcyBub3Qgc3BlY2lmaWNhbGx5IHRhcmdldGVkIHRvIGNvbnN0 cmFpbmVkKS4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNvcmUg W21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJl ciAyMCwgMjAxNSAxMjozNiBBTQ0KPiBUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5j b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQo+IENjOiBDb3JlIDxjb3JlQGlldGYub3Jn PG1haWx0bzpjb3JlQGlldGYub3JnPj4NCj4gU3ViamVjdDogUmU6IFtjb3JlXSBDb01JIENvb2wg ZHJhZnQgc3BsaXRzDQo+DQo+IEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPiBbLi4uXSBJTU8gY29u c3RyYWluZWQgbm9kZXMNCj4gPiB3aWxsIG5ldmVyIGJlIHVzaW5nIHRoZSBzYW1lIG1vZHVsZXMg dGhhdCBhcmUgd3JpdHRlbiBmb3IgbmV0d29ya2luZw0KPiA+IGVxdWlwbWVudC4NCj4NCj4gSXMg dGhhdCBzbz8gIFdoeSB3b3VsZG4ndCBJIHVzZSBhIGNvdXBsZSBvZiBpdGVtcyBmcm9tLCBzYXks IFJGQyA3MzE3DQo+IChvciA3Mjc3KSBpbiBteSBjb25zdHJhaW5lZCBub2RlPyAgSW4gdGhlIGVu ZCB0aGVzZSBhcmUganVzdCByZXNvdXJjZXMNCj4gdGhhdCBJIGFkZCB0byBteSByZXNvdXJjZSB0 cmVlLiAgT2YgY291cnNlLCBjaGVycnktcGlja2luZyBtYXkgcmVxdWlyZQ0KPiBzb21lIGZvcm0g b2Ygc3Vic2V0dGluZyB0aGF0IG1heSBub3QgeWV0IGJlIHBhcnQgb2YgdGhlIE5FVENPTkYgYXBw cm9hY2guDQo+DQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxpc3QNCj4gY29yZUBp ZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb3JlDQoNCg== --_000_BN1PR04MB424B77225FB5E0BFBD088CF921A0BN1PR04MB424namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDEyMzhCLjg4MkFGRDAwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0K PHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93 OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3Jl TWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdh eXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVP dGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6 TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhl bWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRS ZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFN YXJrLz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxt Om1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBt OnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxG cmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0K PG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8 bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0K PG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVm U2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExh dGVudFN0eWxlQ291bnQ9IjM3MSI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp bmRleCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iaW5kZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUg dGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0YWJsZSBvZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJl c3MiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5v dGF0aW9uIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJl bmRub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0ibWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxl dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IEJ1bGxldCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IE51bWJlciA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9z aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVu dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRp bnVlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNz YWdlIEhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx MSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i U2FsdXRhdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9k eSBUZXh0IEZpcnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGlu ZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJCb2R5IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5r Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3Vt ZW50IE1hcCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBU b3Agb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1M IENvZGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQ cmVmb3JtYXR0ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgVmFyaWFibGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJObyBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91 dGxpbmUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFNpbXBsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNz aWMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi bGUgQ29sb3JmdWwgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIENvbHVtbnMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5z IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlk IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIEdyaWQgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIExpc3QgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IExpc3QgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250 ZW1wb3JhcnkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgU3VidGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgV2ViIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFRoZW1lIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGlu ZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1l PSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzNCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5h bWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExp c3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjci IE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBH cmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFt ZT0iTGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0i TWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBO YW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1l PSJNZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5 IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9Ikxp Z2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0 IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29s b3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg TmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFt ZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBO YW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjE5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9 IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5h bWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMzIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxl IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9 IlBsYWluIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDMiIE5hbWU9IlBsYWluIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFi bGUgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYi IE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVs Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU YWJsZSA2IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJs ZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i R3JpZCBUYWJsZSA0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikdy aWQgVGFibGUgNCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEg TGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0 IFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB Y2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlz dCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3Qg VGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp c3QgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3Qg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJv bWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2 ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFy c2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTA3Mzc4NjExMSAxIDAg NDE1IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZv cm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTIu MHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z dHlsZTpub3JtYWw7fQ0Kc3Bhbi5TcGVsbEUNCgl7bXNvLXN0eWxlLW5hbWU6IiI7DQoJbXNvLXNw bC1lOnllczt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tZGVmYXVsdC1wcm9wczp5ZXM7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1z by1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFw ZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25z ICovDQp0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFs IjsNCgltc28tdHN0eWxlLXJvd2JhbmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXpl OjA7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1wYXJlbnQ6IiI7DQoJbXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7 DQoJbXNvLXBhcmEtbWFyZ2luOjBpbjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KPC9zdHlsZT48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ0YWItaW50ZXJ2YWw6LjVpbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+SSBhZ3JlZSB0aGF0IHRoZQ0KPHNwYW4g Y2xhc3M9IlNwZWxsRSI+Q29NSTwvc3Bhbj4gYXBwcm9hY2ggaXMgYmV0dGVyIGluIHRoaXMgcmVz cGVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4gQW5keQ0KIEJpZXJt YW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IE5vdmVtYmVyIDIwLCAyMDE1IDExOjQ5IEFNPGJyPg0KPGI+VG86PC9iPiBSb2RuZXkgQ3VtbWlu Z3MgJmx0O3JvZG5leS5jdW1taW5nc0BuaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDYXJzdGVu IEJvcm1hbm4gJmx0O2NhYm9AdHppLm9yZyZndDs7IENvcmUgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29yZV0gQ29NSSBDb29sIGRyYWZ0IHNwbGl0czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQg d2lsbCBhIGNoYWxsZW5nZSBmb3IgdGhlIENPUkUgV0cgdG8gZ2V0IElBTkEgdG8gbWFuYWdlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgbWFu dWFsIG51bWJlciBhc3NpZ25tZW50IG9mIGV2ZW4gSUVURiBtb2R1bGVzLCBsZXQgYWxvbmUgYWxs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZQU5H IG1vZHVsZXMgZnJvbSBhbGwgdmVuZG9ycyBhbmQgYWxsIG90aGVyIFNET3MuIFRoZSBjb3N0IG9m IGV2ZW4gMSBtaXN0YWtlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pcyByYXRoZXIgaGlnaCAobGlrZSBhIHdyb25nIHBvcnQgYXNzaWdubWVudCku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllB TkcgSGFzaCB3aWxsIGFsbG93IGFueSBZQU5HIG1vZHVsZSB0aGF0IGhhcyBldmVyIGJlZW4gd3Jp dHRlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ b3IgZXZlciBjb3VsZCBiZSB3cml0dGVuIHRvIGJlIHVzZWQgd2l0aG91dCBtb2RpZmljYXRpb24g b3IgbWFudWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5udW1iZXIgYXNzaWdubWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91IGFib3V0IENv TUksIGJ1dCBub3QgQ29PTC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE5vdiAyMCwgMjAxNSBhdCA5OjM2IEFNLCBSb2Ru ZXkgQ3VtbWluZ3MgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2RuZXkuY3VtbWluZ3NAbmkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+cm9kbmV5LmN1bW1pbmdzQG5pLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggQ2Fyc3RlbiBvbiB0aGUg cG9pbnQgYmVsb3cuPGJyPg0KPGJyPg0KQXMgYW4gZXhhbXBsZSwgdGhlIFlBTkcgZGV2ZWxvcG1l bnQgaW4gcHJvZ3Jlc3MgZm9yIDgwMi4xUSBpcyB1c2luZyBmZWF0dXJlcywgYXVnbWVudHMsIGFu ZCBzbyBvbiBpbiBvcmRlciB0byBidWlsZCB1cCBtb2R1bGVzIGZyb20gdGhlIGJhc2ljIGNvbXBv bmVudHMgdG8gbW9yZSBjb21wbGV4IGNvbXBvbmVudHMgKGUuZy4gZm9yIHByb3ZpZGVycykuIFRo ZSBiYXNpYyBjb21wb25lbnRzIGVzc2VudGlhbGx5IHJlcHJlc2VudCB0aGUgaGFyZHdhcmUNCiBy ZWdpc3RlcnMgb2YgYSBzd2l0Y2guIEFzIGNvbnN0cmFpbmVkIHByb2R1Y3RzIGV4cGxvcmUgaW50 ZWdyYXRpb24gb2YgYW4gODAyLjFRIHN3aXRjaCBpbiB0aGVpciBwcm9kdWN0LCB0aGUgcXVlc3Rp b24gb2YgYSBjb25zdHJhaW5lZCBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgY29tZXMgdXAu IElNTyBDb01JL0NvT0wgcHJvdmlkZXMgYW4gZXhjZWxsZW50IHNvbHV0aW9uIGZvciB0aGlzIHVz ZSBjYXNlLCB1c2luZyB0aGUgODAyLjFRIG1vZHVsZShzKQ0KIGZvciBiYXNpYyBjb21wb25lbnRz IChpLmUuIG1vZHVsZXMgbm90IHNwZWNpZmljYWxseSB0YXJnZXRlZCB0byBjb25zdHJhaW5lZCku PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogY29yZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5v cmciPmNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1h bm48YnI+DQomZ3Q7IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjAsIDIwMTUgMTI6MzYgQU08YnI+ DQomZ3Q7IFRvOiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jr cy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogQ29yZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsgU3ViamVjdDogUmU6IFtjb3JlXSBDb01JIENvb2wgZHJhZnQgc3BsaXRzPGJyPg0KJmd0 Ozxicj4NCiZndDsgQW5keSBCaWVybWFuIHdyb3RlOjxicj4NCiZndDsgJmd0OyBbLi4uXSBJTU8g Y29uc3RyYWluZWQgbm9kZXM8YnI+DQomZ3Q7ICZndDsgd2lsbCBuZXZlciBiZSB1c2luZyB0aGUg c2FtZSBtb2R1bGVzIHRoYXQgYXJlIHdyaXR0ZW4gZm9yIG5ldHdvcmtpbmc8YnI+DQomZ3Q7ICZn dDsgZXF1aXBtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElzIHRoYXQgc28/Jm5ic3A7IFdoeSB3 b3VsZG4ndCBJIHVzZSBhIGNvdXBsZSBvZiBpdGVtcyBmcm9tLCBzYXksIFJGQyA3MzE3PGJyPg0K Jmd0OyAob3IgNzI3NykgaW4gbXkgY29uc3RyYWluZWQgbm9kZT8mbmJzcDsgSW4gdGhlIGVuZCB0 aGVzZSBhcmUganVzdCByZXNvdXJjZXM8YnI+DQomZ3Q7IHRoYXQgSSBhZGQgdG8gbXkgcmVzb3Vy Y2UgdHJlZS4mbmJzcDsgT2YgY291cnNlLCBjaGVycnktcGlja2luZyBtYXkgcmVxdWlyZTxicj4N CiZndDsgc29tZSBmb3JtIG9mIHN1YnNldHRpbmcgdGhhdCBtYXkgbm90IHlldCBiZSBwYXJ0IG9m IHRoZSBORVRDT05GIGFwcHJvYWNoLjxicj4NCiZndDs8YnI+DQomZ3Q7IEdyw7zDn2UsIENhcnN0 ZW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhy ZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN1PR04MB424B77225FB5E0BFBD088CF921A0BN1PR04MB424namprd_-- From nobody Fri Nov 20 12:42:23 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02E51B3D8D for ; Fri, 20 Nov 2015 12:42:21 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4raHVnfOWtq for ; Fri, 20 Nov 2015 12:42:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16171B3D8C for ; Fri, 20 Nov 2015 12:42:16 -0800 (PST) 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.331.20; Fri, 20 Nov 2015 20:41:56 +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.0331.019; Fri, 20 Nov 2015 20:41:56 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" , Core Thread-Topic: [core] YANG list to CBOR mapping Thread-Index: AQHRIrIaNU9q4tL9iE+AdF+qow8vM56lToLA Date: Fri, 20 Nov 2015 20:41:55 +0000 Message-ID: References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> In-Reply-To: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 5:Ie1obPC9Ii79jueoE/T7hCtCZ9SmnGKEJLBJFw9oKHnwTof8seROkvYB46ZlVLhqbqfGrpp0CpQgPrAnwtcLmXRPe4n/WjFS0hhxb180e+1Eth4m73EAZj2q+Cs1LhjDbfh+pOwj84ovOD6qmywbYg==; 24:fjW98hlnPdOozgZX2HLX3BLfc1IstZpOVVqTYC6oBYFst16Tjd7K1LEvxsKz3Nsw9KVlBPwSdFcz6TlauZ/3mlujwrVCAB8AXjlQs1mxfYg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1764; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1764; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(38414003)(377454003)(13464003)(199003)(377424004)(19580395003)(101416001)(81156007)(33656002)(2900100001)(15395725005)(19580405001)(5001960100002)(5001770100001)(97736004)(54356999)(189998001)(76176999)(86362001)(5003600100002)(50986999)(106356001)(5002640100001)(99286002)(106116001)(105586002)(122556002)(15975445007)(74316001)(92566002)(66066001)(5004730100002)(586003)(40100003)(77096005)(2950100001)(2501003)(76576001)(10400500002)(87936001)(5007970100001)(15974865002)(5008740100001)(11100500001)(102836003)(6116002)(3846002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1: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: 20 Nov 2015 20:41:55.5910 (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: "ana@ackl.io" Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 20:42:22 -0000 UmVmZXJlbmNlOiBZQU5HIGxpc3QgdG8gQ0JPUiBtYXBwaW5nIGh0dHBzOi8vY29yZS13Zy5naXRo dWIuaW8veWFuZy1jYm9yLyNyZmMuc2VjdGlvbi4zLjEuMTcNCg0KSGkgUGV0ZXINCg0KWW91ciBw cm9wb3NlZCBzb2x1dGlvbiBmb3IgbGlzdHMgaGF2ZSBzb21lIGRyYXdiYWNrcyBhbmQgSSdsbCBs aWtlIHRvIHVuZGVyc3RhbmQgYmV0dGVyIGl0cyBhZHZhbnRhZ2VzIHRvIGV2YWx1YXRlIHRoZSBQ Uk9TIGFuZCBDT05TLiANCg0KTGlzdCBvZiBDT05TDQotIFlvdXIgcHJvcG9zZWQgc29sdXRpb24g aXMgbm90IGFsaWduZWQgd2l0aCBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLWpzb24tMDYNCi0gWW91 ciBwcm9wb3NlZCBzb2x1dGlvbiB0YWtlIG9uZSBleHRyYSBieXRlIHBlciBsaXN0IGVudHJ5DQot IFlvdXIgcHJvcG9zZWQgc29sdXRpb24gdXNlIGEgbWFwIGFzIGtleSBmb3IgYSBtYXAsIHdoaWNo IGlzIHVuY29tbW9uIChJbGxlZ2FsIGluIEpTT04gYnV0IG5vdCBpbiBDQk9SKQ0KLSBUaGUgZW5j b2Rpbmcgb2YgbGlzdCBkZWZpbmVkIHdpdGgga2V5cyBvciB3aXRob3V0IGtleXMgYXJlIGRvbmUg ZGlmZmVyZW50bHkNCg0KQ29NSS1Db09MIGNsaWVudHMgYW5kIHNlcnZlcnMga25vd24gd2hpY2gg ZGF0YSBub2RlcyBvZiBhIGxpc3QgYXJlIGtleXMgYW5kIHdoaWNoIG9uZXMgYXJlIGFzc29jaWF0 ZWQgaW5mb3JtYXRpb24uDQpJIGRvbuKAmXQgdGhlIHNlZSB2YWx1ZSBvZiBpbXBsZW1lbnRpbmcg dGhlIGtleXMgb24gdGhlIGxlZnQgc2lkZSBvZiB0aGUgJzonIChrZXkpIGFuZCB0aGUgcmVzdCBv ZiB0aGUgZGF0YSBub2RlcyBvbiB0aGUgcmlnaHQgc2lkZSBvZiB0aGUgJzoiICh2YWx1ZSkuDQpU aGlzIHNlbWFudGljIGlzIGFscmVhZHkga25vd24gYnkgYm90aCBlbmRzLCB3aHkgd2UgbmVlZCB0 byBhZGQgaXQgdG8gdGhlIGVuY29kaW5nPw0KDQo9PT0gRXhhbXBsZXMNCg0KTWFwIG9mIG1hcCBz b2x1dGlvbiB3aXRoIENvTUkgSURzICg4OCBCeXRlcykNCiAgew0KICAgIDExMTExMTExIDogew0K ICAgICAgezIyMjIyMjIyIDogImJvb2sxIiwgMzMzMzMzMzMgOiAiYXV0aG9yMiJ9IDogezQ0NDQ0 NDQ0IDogNTAwLCA1NTU1NTU1NTogNjZ9ICwNCiAgICAgIHsyMjIyMjIyMiA6ICJib29rNSIsIDMz MzMzMzMzIDogImF1dGhvcjMifSA6IHs0NDQ0NDQ0NCA6IDQ0NCwgNTU1NTU1NTU6IDExfQ0KICAg IH0NCiAgfQ0KDQpBcnJheSBvZiBtYXAgc29sdXRpb24gd2l0aCBDb01JIElEcyAoODYgQnl0ZXMp DQogIHsNCiAgICAxMTExMTExMSA6IFsNCiAgICAgIHsNCiAgICAgICAgMjIyMjIyMjIgOiAiYm9v azEiLA0KICAgICAgICAzMzMzMzMzMyA6ICJhdXRob3IyIiwNCiAgICAgICAgNDQ0NDQ0NDQgOiA1 MDAsDQogICAgICAgIDU1NTU1NTU1OiA2Ng0KICAgICAgfSAsDQogICAgICB7DQogICAgICAgIDIy MjIyMjIyIDogImJvb2s1IiwNCiAgICAgICAgMzMzMzMzMzMgOiAiYXV0aG9yMyIsDQogICAgICAg IDQ0NDQ0NDQ0IDogNDQ0LA0KICAgICAgICA1NTU1NTU1NTogMTENCiAgICAgIH0NCiAgICBdDQog IH0NCg0KTWFwIG9mIG1hcCBzb2x1dGlvbiB3aXRoIENvT0wgSURzICg1NiBCeXRlcykNCg0KICAg IHsNCiAgICAgIDExMTExMTExIDogew0KICAgICAgICB7MiA6ICJib29rMSIsIDMgOiAiYXV0aG9y MiJ9IDogezQgOiA1MDAsIDU6IDY2fSAsDQogICAgICAgIHsyIDogImJvb2s1IiwgMyA6ICJhdXRo b3IzIn0gOiB7NCA6IDQ0NCwgNTogMTF9DQogICAgICB9DQogICAgfQ0KDQpBcnJheSBvZiBtYXAg c29sdXRpb24gd2l0aCBDb09MIElEcyAoNTQgQnl0ZXMpDQoNCiAgICB7DQogICAgICAxMTExMTEx MSA6IFsNCiAgICAgICAgew0KICAgICAgICAgIDIgOiAiYm9vazEiLA0KICAgICAgICAgIDMgOiAi YXV0aG9yMiIsDQogICAgICAgICAgNCA6IDUwMCwNCiAgICAgICAgICA1OiA2Ng0KICAgICAgICB9 ICwNCiAgICAgICAgew0KICAgICAgICAgIDIgOiAiYm9vazUiLA0KICAgICAgICAgIDMgOiAiYXV0 aG9yMyIsDQogICAgICAgICAgNCA6IDQ0NCwNCiAgICAgICAgICA1OiAxMQ0KICAgICAgICB9DQog ICAgICBdDQogICAgfQ0KDQpZb3Ugc2F5ICJJdCBpcyB0aGUgd2lzaCB0byB0cmFuc3BvcnQgb25s eSB0aG9zZSBsaXN0IGVsZW1lbnRzIHdpdGggYSB1bmlxdWUga2V5IHZhbHVlLCBlaXRoZXIgdG8g c3VwcG9ydCBhIFBBVENIIG9yIGEgRkVUQ0ggY29tbWFuZCIuDQpJIGRvbuKAmXQgc2VlIHdoeSB0 aGlzIGlzIG5vdCB0aGUgY2FzZSBmb3IgYm90aCByZXByZXNlbnRhdGlvbnMuDQoNCk1pY2hlbCBW ZWlsbGV0dGUNClN5c3RlbSBBcmNoaXRlY3R1cmUgRGlyZWN0b3INClRyaWxsaWFudCBJbmMuDQpU ZWw6IDQ1MC0zNzUtMDU1NiBleHQuIDIzNw0KbWljaGVsLnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMu Y29tDQp3d3cudHJpbGxpYW50aW5jLmNvbSDCoCANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIHBldGVyIHZhbiBkZXIgU3Rvaw0KU2VudDogTm92ZW1iZXItMTktMTUgNTowNiBBTQ0KVG86 IENvcmUgPGNvcmVAaWV0Zi5vcmc+DQpDYzogbGhvdGthQG5pYy5jeg0KU3ViamVjdDogW2NvcmVd IFlBTkcgbGlzdCB0byBDQk9SIG1hcHBpbmcNCg0KSGkgQ29PTCBhdXRob3JzLA0KDQpUaGlzIGVf bWFpbCBjb21wbGVtZW50cyBteSBlYXJsaWVyIGUtbWFpbCBvbiBZQU5HIHRvIENCT1IgbWFwcGlu ZywgYW5kIGV4cGxhaW5zIHRoZSBwcm9wb3NlZCBsaXN0IGVuY29kaW5nLg0KDQpCb3RoIHRoZSBk cmFmdCB5YW5nLWpzb24gYW5kIHRoZSBDb09MIGRyYWZ0IGVuY29kZSBhIGxpc3QgYXMgYW4gYXJy YXkuIA0KSW4gdGhlIHlhbmctanNvbiBjYXNlIGFzIGEgSlNPTiBhcnJheSwgYW5kIGluIHRoZSBD b09MIGNhc2UgYXMgbWFqb3IgdHlwZSA0IG9mIG1ham9yIHR5cGUgNSBvYmplY3RzLg0KVGhpcyBl bmNvZGluZyBwcmV2ZW50cyB0aGUgc2VsZWN0aW9uIG9mIGxpc3QgaW5zdGFuY2VzIG9uIHRoZSBi YXNpcyBvZiB0aGUga2V5IHZhbHVlcyBmcm9tIHRoZSBwYXlsb2FkIGFsb25lLiBJbiBDb01JIHRo ZSBsaXN0IGlzIGVuY29kZWQgYXMgYSBtYWpvciB0eXBlIDUgb2YgbWFqb3IgdHlwZSA1IG9iamVj dHMuIFRoaXMgZGV2aWF0aW9uIGZyb20gdGhlIHlhbmctanNvbiBtYXBwaW5nIGlzIG1vdGl2YXRl ZCBieSB0aGUgd2lzaCB0byB0cmFuc3BvcnQgaW5kaXZpZHVhbCBsaXN0IGluc3RhbmNlcyBhbmQg aWRlbnRpZnkgdGhlIGluc3RhbmNlcyBpbiB0aGUgcGF5bG9hZCBmcm9tIHRoZSBrZXkgdmFsdWVz LiBUaGlzIGlzIGVzcGVjaWFsbHkgaW1wb3J0YW50IGluIGNhc2Ugb2YgUEFUQ0ggb3BlcmF0aW9u IG9uIGxpc3QgaW5zdGFuY2VzLg0KVHdvIGNhc2VzIGFyZSB0byBiZSBsb29rZWQgYXQ6ICgxKSB0 aGUgbGlzdCBkZWZpbml0aW9uIHNwZWNpZmllcyBvbmUgb3IgbW9yZSBrZXkgZWxlbWVudHMsIGFu ZCAoMikgdGhlIGxpc3QgZGVmaW5pdGlvbiBkb2VzIG5vdCBzcGVjaWZ5IGEga2V5IGVsZW1lbnQu IFdlIHdpbGwgc3RhcnQgd2l0aCBhIGxpc3QgY29udGFpbmluZyBrZXkgZWxlbWVudHMuDQpJdCBp cyB0aGUgd2lzaCB0byB0cmFuc3BvcnQgb25seSB0aG9zZSBsaXN0IGVsZW1lbnRzIHdpdGggYSB1 bmlxdWUga2V5IHZhbHVlLCBlaXRoZXIgdG8gc3VwcG9ydCBhIFBBVENIIG9yIGEgRkVUQ0ggY29t bWFuZC4gVGhlcmVmb3JlIGl0IGlzIHJlcXVpcmVkIHRoYXQgdGhlIHBheWxvYWQgYWxsb3dzIHRo ZSBzZWxlY3Rpb24gYW5kIGlkZW50aWZpY2F0aW9uIG9mIHRoZXNlIGxpc3QgZWxlbWVudCBvbiB0 aGUgYmFzaXMgb2YgdGhlaXIga2V5IHZhbHVlcy4gVXNpbmcgdGhlIGRpYWdub3N0aWMgSlNPTiBu b3RhdGlvbiB1c2VkIGZvciBDQk9SIGRpYWdub3N0aWNzLCB0aGUgcGF5bG9hZCBjb250YWluaW5n IGEgbnVtYmVyIG9mIGVsZW1lbnRzIHdpdGgga2V5IHZhbHVlcyBzaG91bGQgbG9vayBsaWtlIGEg SlNPTiBvYmplY3Qgd2l0aCB0aGUgc3RydWN0dXJlIGxpc3QtbmFtZToge2tleTogdmFsdWV9LiBC b3RoIGtleSBhbmQgdmFsdWUgYXJlIGNvbXBvc2VkIG9mIEpTT04gb2JqZWN0cyBzZXBhcmF0ZWQg YnkgY29tbWFzLiBGb3IgZXhhbXBsZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIFlBTkcgbGlzdCBz cGVjaWZpY2F0aW9uOg0KbW9kdWxlIGZvbyB7DQogICAgIG5hbWVzcGFjZSBodHRwOi8vZXhhbXBs ZS5jb20vYm9vazsNCiAgICAgcHJlZml4IOKAnGZv4oCdOw0KICAgICByZXZpc2lvbiAgMjAxNS0w Ni0wNzsNCg0KICAgIGxpc3QgQiB7DQogICAgICAga2V5IOKAnGtleTEga2V5MuKAnTsNCiAgICAg ICBsZWFmIGtleTEge3R5cGUgc3RyaW5nO30NCiAgICAgICBsZWFmIGtleTIge3R5cGUgc3RyaW5n O30NCiAgICAgICBsZWFmIGNvbGwge3R5cGUgaW50MzI7fQ0KICAgICAgIGxlYWYgY291bnRlciB7 dHlwZSBpbnQzMjt9DQogICAgfQ0KfQ0KDQpDb25zaWRlciB0aGUgdHJhbnNwb3J0IG9mIHR3byBp bnN0YW5jZXMgc3BlY2lmaWVkIGJ5IDzigJxrZXkx4oCdID0g4oCcYm9vazHigJ0sIOKAnGtleTLi gJ0gPSDigJxhdXRob3Iy4oCdPiBhbmQgYnkgPOKAnGtleTHigJ0gPSDigJxib29rNeKAnSwg4oCc a2V5MuKAnSA9IOKAnGF1dGhvcjPigJ0+IG91dCBvZiBhIGxhcmdlciBzZXQgb2YgaW5zdGFuY2Vz LiBUaGUgcmVwcmVzZW50YXRpb24gaXMgZGlmZmVyZW50IGZyb20gdGhlIHlhbmctanNvbiBvbmUg Zm9yIHRoZSByZWFzb25zIGV4cGxhaW5lZCBhYm92ZS4NCg0KVGhlIHBheWxvYWQgd2lsbCBsb29r IGxpa2U6DQp7IkIiIDp7DQogICAgIHsia2V5MSIgOiAiYm9vazEiLCAia2V5MiIgOiAiYXV0aG9y MiJ9IDoNCiAgICAgeyJjb2xsIiA6IDUwMCwgImNvdW50ZXIiOiA2Nn0gLA0KICAgICB7ImtleTEi IDogImJvb2s1IiwgImtleTIiIDogImF1dGhvcjMifSA6DQogICAgIHsiY29sbCIgOiA0NDQsICJj b3VudGVyIjogMTF9DQogICAgIH0NCn0NCg0KDQpXaGljaCB0cmFuc2xhdGVkIHRvIENCT1IgeWll bGRzOg0KDQphMSAgICAgICAgICAgICAgICAgICAgICAgICAjIG1hcCgxKQ0KICAgIDYxICAgICAg ICAgICAgICAgICAgICAgICMgdGV4dCgxKQ0KICAgICAgIDQyICAgICAgICAgICAgICAgICAgICMg IkIiDQogICAgYTIgICAgICAgICAgICAgICAgICAgICAgIyBtYXAoMikNCiAgICAgICBhMiAgICAg ICAgICAgICAgICAgICAjIG1hcCgyKQ0KICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4 dCg0KQ0KICAgICAgICAgICAgIDZiNjU3OTMxICAgICAgICMgImtleTEiDQogICAgICAgICAgNjUg ICAgICAgICAgICAgICAgIyB0ZXh0KDUpDQogICAgICAgICAgICAgNjI2ZjZmNmIzMSAgICAgIyAi Ym9vazEiDQogICAgICAgICAgNjQgICAgICAgICAgICAgICAgIyB0ZXh0KDQpDQogICAgICAgICAg ICAgNmI2NTc5MzIgICAgICAgIyAia2V5MiINCiAgICAgICAgICA2NyAgICAgICAgICAgICAgICAj IHRleHQoNykNCiAgICAgICAgICAgICA2MTc1NzQ2ODZmNzIzMiAjICJhdXRob3IyIg0KICAgICAg IGEyICAgICAgICAgICAgICAgICAgICMgbWFwKDIpDQogICAgICAgICAgNjQgICAgICAgICAgICAg ICAgIyB0ZXh0KDQpDQogICAgICAgICAgICAgNjM2ZjZjNmMgICAgICAgIyAiY29sbCINCiAgICAg ICAgICAxOSAwMWY0ICAgICAgICAgICAjIHVuc2lnbmVkKDUwMCkNCiAgICAgICAgICA2NyAgICAg ICAgICAgICAgICAjIHRleHQoNykNCiAgICAgICAgICAgICA2MzZmNzU2ZTc0NjU3MiAjICJjb3Vu dGVyIg0KICAgICAgICAgIDE4IDQyICAgICAgICAgICAgICMgdW5zaWduZWQoNjYpDQogICAgICAg YTIgICAgICAgICAgICAgICAgICAgIyBtYXAoMikNCiAgICAgICAgICA2NCAgICAgICAgICAgICAg ICAjIHRleHQoNCkNCiAgICAgICAgICAgICA2YjY1NzkzMSAgICAgICAjICJrZXkxIg0KICAgICAg ICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4dCg1KQ0KICAgICAgICAgICAgIDYyNmY2ZjZiMzUg ICAgICMgImJvb2s1Ig0KICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4dCg0KQ0KICAg ICAgICAgICAgIDZiNjU3OTMyICAgICAgICMgImtleTIiDQogICAgICAgICAgNjcgICAgICAgICAg ICAgICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjE3NTc0Njg2ZjcyMzMgIyAiYXV0aG9yMyIN CiAgICAgICBhMiAgICAgICAgICAgICAgICAgICAjIG1hcCgyKQ0KICAgICAgICAgIDY0ICAgICAg ICAgICAgICAgICMgdGV4dCg0KQ0KICAgICAgICAgICAgIDYzNmY2YzZjICAgICAgICMgImNvbGwi DQogICAgICAgICAgMTkgMDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQogICAgICAgICAg NjcgICAgICAgICAgICAgICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjM2Zjc1NmU3NDY1NzIg IyAiY291bnRlciINCiAgICAgICAgICAwYiAgICAgICAgICAgICAgICAjIHVuc2lnbmVkKDExKQ0K DQpUaGUgY29ycmVzcG9uZGluZyB5YW5nLWpzb24gZHJhZnQgZW5jb2RpbmcgLSB0aGF0IGFsbG93 cyB0cmFuc3BvcnQgb2YgYSBzZWxlY3Rpb24gb2YgaW5zdGFuY2VzLSBkb2VzIG5vdCBzcGVjaWZ5 IHRoZSBrZXkgZmllbGRzIGFuZCB3b3VsZCBoYXZlIGxvb2tlZCBsaWtlOg0KDQp7IkIiIDogWw0K ICAgICB7ImtleTEiIDogImJvb2sxIiwNCiAgICAgICAia2V5MiIgOiAiYXV0aG9yMuKAnSwNCiAg ICAgICAgImNvbGwiIDogNTAwLA0KICAgICAgICAiY291bnRlciI6IDY2DQogICAgICB9ICwNCiAg ICAgeyJrZXkxIiA6ICJib29rNSIsDQogICAgICAgImtleTIiIDogImF1dGhvcjMiLA0KICAgICAg ICJjb2xsIiA6IDQ0NCwNCiAgICAgICAiY291bnRlciI6IDExLA0KICAgICB9DQogICBdDQp9DQoN ClN1cHBvc2UgdGhlcmUgYXJlIG5vIGtleSBlbGVtZW50cyBzcGVjaWZpZWQuIEluIHRoYXQgY2Fz ZSBpdCBpcyBpbXBvc3NpYmxlIHRvIHNwZWNpZnkgdGhlIHdhbnRlZCBsaXN0IGVsZW1lbnRzLCBh bmQgYWx3YXlzIHRoZSB3aG9sZSBsaXN0IG11c3QgYmUgdHJhbnNwb3J0ZWQuIEluIHRoZSBjYXNl IG9mIGEgbGlzdCB3aXRob3V0IGtleSBzcGVjaWZpY2F0aW9uIGlzIGlzIGJlc3QgdG8gdXNlIG1h am9yIHR5cGUgNCBjb21wb3NlZCBvZiBtYWpvciB0eXBlIDUgdG8gdHJhbnNwb3J0IHRoZSBsaXN0 LCBhcyBpcyBzcGVjaWZpZWQgaW4geWFuZy1qc29uIGRyYWZ0Lg0KDQpDb25zaWRlciB0aGUgZm9s bG93aW5nIFlBTkcgbGlzdA0KDQpNb2R1bGUgZm9vew0KICAgICBOYW1lc3BhY2UgaHR0cDovL2V4 YW1wbGUuY29tL2Jvb2s7DQogICAgIFByZWZpeCDigJxib+KAnQ0KICAgICBSZXZpc2lvbiAgMjAx NS0wNi03DQpMaXN0IEIgew0KICAgIExlYWYgdGl0bGUge3R5cGUgc3RyaW5nO30NCiAgICBMZWFm IGF1dGhvciB7dHlwZSBzdHJpbmc7fQ0KICAgIExlYWYgY29sbCB7dHlwZSBpbnQzMn0NCiAgICBM ZWFmIGNvdW50ZXIge3R5cGUgaW50MzJ9DQogICAgfQ0KfQ0KDQpTdXBwb3NlIHRoZSBsaXN0IGNv bnRhaW5zIHR3byBlbGVtZW50cy4gVGhlIHRyYW5zcG9ydCBwYXlsb2FkIG9mIHRoZSB0d28gZWxl bWVudHMgbG9va3MgbGlrZToNCg0KeyJCIiA6Ww0KICAgICB7InRpdGxlIiA6ICJib29rMSIsICJh dXRob3IiIDogImF1dGhvcjIiLCAiY29sbCIgOiA1MDAsICJjb3VudGVyIjogDQo2Nn0gLA0KICAg ICB7InRpdGxlIiA6ICJib29rNSIsICJhdXRob3IiIDogImF1dGhvcjMiLCAg4oCcY29sbCIgOiA0 NDQsICJjb3VudGVyIjogDQoxMX0NCiAgICAgXQ0KfQ0KDQpUaGlzIHBheWxvYWQgaXMgaWRlbnRp Y2FsIHRvIHRoZSB5YW5nLWpzb24gcGF5bG9hZC4NCldoaWNoIHlpZWxkcyB0aGUgY29ycmVzcG9u ZGluZyBDQk9SIGNvZGUuDQoNCmExICAgICAgICAgICAgICAgICAgICAgICAgICMgbWFwKDEpDQog ICAgNjEgICAgICAgICAgICAgICAgICAgICAgIyB0ZXh0KDEpDQogICAgICAgNDIgICAgICAgICAg ICAgICAgICAgIyAiQiINCiAgICA4MiAgICAgICAgICAgICAgICAgICAgICAjIGFycmF5KDIpDQog ICAgICAgYTQgICAgICAgICAgICAgICAgICAgIyBtYXAoNCkNCiAgICAgICAgICA2NSAgICAgICAg ICAgICAgICAjIHRleHQoNSkNCiAgICAgICAgICAgICA3NDY5NzQ2YzY1ICAgICAjICJ0aXRsZSIN CiAgICAgICAgICA2NSAgICAgICAgICAgICAgICAjIHRleHQoNSkNCiAgICAgICAgICAgICA2MjZm NmY2YjMxICAgICAjICJib29rMSINCiAgICAgICAgICA2NiAgICAgICAgICAgICAgICAjIHRleHQo NikNCiAgICAgICAgICAgICA2MTc1NzQ2ODZmNzIgICAjICJhdXRob3IiDQogICAgICAgICAgNjcg ICAgICAgICAgICAgICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjE3NTc0Njg2ZjcyMzIgIyAi YXV0aG9yMiINCiAgICAgICAgICA2NCAgICAgICAgICAgICAgICAjIHRleHQoNCkNCiAgICAgICAg ICAgICA2MzZmNmM2YyAgICAgICAjICJjb2xsIg0KICAgICAgICAgIDE5IDAxZjQgICAgICAgICAg ICMgdW5zaWduZWQoNTAwKQ0KICAgICAgICAgIDY3ICAgICAgICAgICAgICAgICMgdGV4dCg3KQ0K ICAgICAgICAgICAgIDYzNmY3NTZlNzQ2NTcyICMgImNvdW50ZXIiDQogICAgICAgICAgMTggNDIg ICAgICAgICAgICAgIyB1bnNpZ25lZCg2NikNCiAgICAgICBhNCAgICAgICAgICAgICAgICAgICAj IG1hcCg0KQ0KICAgICAgICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4dCg1KQ0KICAgICAgICAg ICAgIDc0Njk3NDZjNjUgICAgICMgInRpdGxlIg0KICAgICAgICAgIDY1ICAgICAgICAgICAgICAg ICMgdGV4dCg1KQ0KICAgICAgICAgICAgIDYyNmY2ZjZiMzUgICAgICMgImJvb2s1Ig0KICAgICAg ICAgIDY2ICAgICAgICAgICAgICAgICMgdGV4dCg2KQ0KICAgICAgICAgICAgIDYxNzU3NDY4NmY3 MiAgICMgImF1dGhvciINCiAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCiAg ICAgICAgICAgICA2MTc1NzQ2ODZmNzIzMyAjICJhdXRob3IzIg0KICAgICAgICAgIDY0ICAgICAg ICAgICAgICAgICMgdGV4dCg0KQ0KICAgICAgICAgICAgIDYzNmY2YzZjICAgICAgICMgImNvbGwi DQogICAgICAgICAgMTkgMDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQogICAgICAgICAg NjcgICAgICAgICAgICAgICAgIyB0ZXh0KDcpDQogICAgICAgICAgICAgNjM2Zjc1NmU3NDY1NzIg IyAiY291bnRlciINCiAgICAgICAgICAwYiAgICAgICAgICAgICAgICAjIHVuc2lnbmVkKDExKQ0K DQoNCi0tDQpQZXRlciB2YW4gZGVyIFN0b2sNCnZhbmRlcnN0b2sgY29uc3VsdGFuY3kNCm1haWx0 bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg== From nobody Fri Nov 20 13:15:11 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050C61B3E10; Fri, 20 Nov 2015 13:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY3MimBxeSTU; Fri, 20 Nov 2015 13:15:09 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33421B3E0E; Fri, 20 Nov 2015 13:15:08 -0800 (PST) Received: by vkbs1 with SMTP id s1so6007010vkb.1; Fri, 20 Nov 2015 13:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=fW9BB1eYzR5Q/Pd2YhMxZuLd0a9gagYgljgJwdvaGnE=; b=r2zq++TmgYrCUlheXGF+bN9QA7NWiwqFDaw47mu50lCC6wzzA0mS+k7yeYpzjSwaOt HUk12mNNLLRDyDdOudd81OmEYTdS1rMjJr80i6F3COmUHeOg5cOFZR7NHn8iWUKYacan TBJDM8dg5zF9wGcVLBWxNFt3VVbUTNYDRiNpUUnLqP2MZXoX6xAzhQoJiIRbMUl8f8mo QZjPet6mVzhREWOlIEZZA1LVYn1900hqN3ilolg4YQyXCgOD7ebATVdiC/CBR90+HpY5 su4eCj5WPTASykRoX3c+aH0IdBdB7O26Fx5BwZ3Ofdfr73t62T13klzQJtyq2CiC2qvX b0Fw== MIME-Version: 1.0 X-Received: by 10.31.150.135 with SMTP id y129mr1579679vkd.156.1448054108112; Fri, 20 Nov 2015 13:15:08 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.31.182.135 with HTTP; Fri, 20 Nov 2015 13:15:08 -0800 (PST) Date: Fri, 20 Nov 2015 16:15:08 -0500 X-Google-Sender-Auth: qSF31YCKEy-YejtxLJB1Un-AkxM Message-ID: From: Barry Leiba To: draft-ietf-core-block@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: core WG Subject: [core] AD review of draft-ietf-core-block-18 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Nov 2015 21:15:10 -0000 My apologies for the long delay in handling this publication request: I've had a month straight of travel, including a little personal vacation at the beginning and end. I'm back and running full steam, and reviewing the backlog of publication requests from several working groups. Thanks for the patience. My only two comments are editorial, and need not get in the way of last call, so I'll be requesting last call as soon as I send this message. -- Abstract -- It's not a big deal, but I find the abstract unusually long and with unnecessary detail. It should specify *what* the document does, and leave the *why* to the Introduction. I really think that this is sufficient for the Abstract: NEW Applications that use the Constrained Application Protocol (CoAP) occasionally need to transfer comparatively large payloads -- for instance, for firmware updates. 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. The Block options provide a minimal way to transfer larger representations in a block-wise fashion. END -- Section 1 -- Please expand "CoAP" and "REST" on first use in the Introduction (for the latter, in the second line for "REST architecture"). -- Barry From nobody Fri Nov 20 13:32:53 2015 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 76C031B3E60; Fri, 20 Nov 2015 13:32:50 -0800 (PST) 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.10.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> Date: Fri, 20 Nov 2015 13:32:50 -0800 Archived-At: Cc: draft-ietf-core-block@ietf.org, core-chairs@ietf.org, barryleiba@gmail.com, core@ietf.org Subject: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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, 20 Nov 2015 21:32:50 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Block-wise transfers in CoAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-core-block/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Nov 20 19:20:47 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32621A1A7D for ; Fri, 20 Nov 2015 19:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QIJ0XtO9LGw for ; Fri, 20 Nov 2015 19:20:41 -0800 (PST) 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 0B0471A1A7F for ; Fri, 20 Nov 2015 19:20:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAP67456; Sat, 21 Nov 2015 03:20:37 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 21 Nov 2015 03:20:35 +0000 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.211]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Sat, 21 Nov 2015 11:20:28 +0800 From: "zhengfei (E)" To: "cabo@tzi.org" Thread-Topic: Re: a question about the Message Format in draft-tschofenig-core-coap-tcp-tls-00 Thread-Index: AQHRJAuRshW4SsuulU+iuzBYkb95Vw== Date: Sat, 21 Nov 2015 03:20:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.23.52] Content-Type: multipart/alternative; boundary="_000_C6223E7F04FAF9418F0C162994D4E8339AE621szxeml513mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.564FE305.0086, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.211, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 86e94587f591ee27ce54d78ba45b5e39 Archived-At: Cc: "core@ietf.org" Subject: Re: [core] a question about the Message Format in draft-tschofenig-core-coap-tcp-tls-00 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 21 Nov 2015 03:20:44 -0000 --_000_C6223E7F04FAF9418F0C162994D4E8339AE621szxeml513mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEJvcm1hbm4NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBxdWljayB1cGRhdGlu ZyB0byAtMDEsDQpJIHRoaW5rIGEgY2xlYXIgdW5pZm9ybSBzY2hlbWUoTDEgb25seSkgY291bGQg Z3JlYXRseSBpbXByb3ZlIHRoZSBjb21wYXRpYmlsaXR5IGJldHdlZW4gZGlmZmVyZW50IGltcGxl bWVudGF0aW9ucy4NCg0KVGhlIHNpbXBsZSA0LWJ5dGUgVENQLUNvQVAgcGFja2V0IGhlYWQgd2hv c2UgbGVuZ3RoIGlzIHNhbWUgdG8gVURQLUNvQVAgcmVhbGx5IGxvb2tzIGdvb2QsDQplc3BlY2lh bGx5IHdoZW4gQ29BUCBzdGFjayB3aWxsIGltcGxlbWVudCB0byBiZSBhIGR1YWwgc3RhY2ssIHdo byBzdXBwb3J0cyBib3RoIG92ZXIgVURQIGFuZCBvdmVyIFRDUCBzaW11bHRhbmVvdXNseS4NCkkg d2lsbCBtb2RpZnkgb3VyIGltcGxlbWVudGF0aW9uIGZyb20gTDMgdG8gTDEgdG9vLCBmb2xsb3dp bmcgdGhpcyB1cGRhdGVkIGRyYWZ0Lg0KLS0tLS0tLQ0KRmluYWxseSwgc29ycnkgdGhhdCBJIGhh dmUgdXNlZCBteSBwcml2YXRlIGVtYWlsIGFuZCBhbiBlbXB0eSBuYW1lIHByZXZpb3VzbHksIG15 IG5hbWUgaXMgWmhlbmcgRmVpLg0KVGhhbmtzIGFnYWluLuKYug0KDQotLS0tLS0tLS0tLS0tLS0t LS0g5Y6f5aeL6YKu5Lu2IC0tLS0tLS0tLS0tLS0tLS0tLQ0K5Y+R5Lu25Lq6OiBDYXJzdGVuIEJv cm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4NCuWPkemAgeaXtumXtDog MjAxNeW5tDEx5pyIMjDml6UgMDE6MTMNCuaUtuS7tuS6ujogNzc0MTYzIDw3NzQxNjNAcXEuY29t PG1haWx0bzo3NzQxNjNAcXEuY29tPj4NCuaKhOmAgTogc2xlbWF5IDxzbGVtYXlAemVicmEuY29t PG1haWx0bzpzbGVtYXlAemVicmEuY29tPj4sIHZzb2xvcnphbm9iYXJib3phIDx2c29sb3J6YW5v YmFyYm96YUB6ZWJyYS5jb208bWFpbHRvOnZzb2xvcnphbm9iYXJib3phQHplYnJhLmNvbT4+LCBI YW5uZXMudHNjaG9mZW5pZyA8SGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86SGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4+DQrkuLvpopg6IFJlOiBhIHF1ZXN0aW9uIGFib3V0IHRoZSBN ZXNzYWdlIEZvcm1hdCBpbiBkcmFmdC10c2Nob2ZlbmlnLWNvcmUtY29hcC10Y3AtdGxzLTAwDQoN CkhpIDc3NDE2MywNCg0KKGhvdyBkbyB5b3UgcHJvbm91bmNlIHlvdXIgbmFtZT8gOi0pDQoNCj4g SSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIGxhdGVzdCBkb2N1bWVudCBub3cuDQo+IEFib3V0 IHRoZSBNZXNzYWdlIEZvcm1hdCwgSW4gc2VjdGlvbiA0LCBJIGNhbiBzZWUgdGhhdCB5b3UgY2hv b3NlIHRoZSBMMQ0KPiBzY2hlbWUsIGFuZCBubyBvdGhlciBzY2hlbWVzIGFyZSBtZW50aW9uZWQs IHNvIGlmIEkgY2FuIGRyYXcgY29uY2x1c2lvbg0KPiB0aGF0IEwxIGlzIHRoZSBkcmFmdCBzdGFu ZGFyZCwgYW5kIG90aGVyIHNjaGVtZXMgYXJlIE5vIGxvbmdlciB3aXRoaW4NCj4gdGhlIHNjb3Bl IG9mIHRoZSBjb25zaWRlcmF0aW9uPw0KDQpUaGF0IGlzIHRoZSByZXN1bHQgb2YgdGhlIFlva29o YW1hIG1lZXRpbmcgYW5kIHRoZSBjb25zZW5zdXMgY2FsbCB3ZSBoYWQNCmFmdGVyIHRoYXQuDQoN Cj4gQnV0IGluIHNlY3Rpb24gMyAtLT4gInVubGVzcyBhbHRlcm5hdGl2ZSBMMyBiZWxvdyBpcyBj aG9zZW4iDQo+IEl0IHNlZW1zIHRoYXQgb3RoZXIgc2NoZW1lcyBhcmUgc3RpbGwgdmFsaWQ/IEkn bSByZWFsbHkgY29uZnVzZWQgYWJvdXQgdGhpcy4NCg0KT29wcy4NCg0KRmFpbGluZyB0byByZW1v dmUgdGhpcyByZW1uYW50IHdhcyBteSBlZGl0b3JpYWwgb3ZlcnNpZ2h0Lg0KVGhhbmsgeW91IGZv ciBhbGVydGluZyB1cy4gIEkganVzdCBzdWJtaXR0ZWQgYW4gdXBkYXRlLCAtMDEsIHRvIHJlbW92 ZQ0KdGhpcyBjb25mdXNpbmcgcGFzc2FnZS4NCg0KPiBJIHRoaW5rIG1vc3QgdXNlcnMgYXJlIGhl c2l0YXRpbmcgYmV0d2VlbiBMMSBhbmQgTDMuIEFjdHVhbGx5IHdlIGhhdmUNCj4gaW1wbGVtZW50 IHRoZSBMMyBzY2hlbWUgYnV0IEkgcmVhbGx5IGxpa2UgTDEgc2NoZW1lLg0KDQpJbmRlZWQsIHRo ZSBXRyBoYXMgYmVlbiBoZXNpdGF0aW5nIGEgd2hpbGUgYXMgd2VsbC4NCkluIHRoZSBlbmQsIHRo ZSBzaW1wbGljaXR5IG9mIEwxIHdvbiBvdmVyIHRoZSBnZW5lcmFsaXR5IChhbmQgc2xpZ2h0bHkN CmltcHJvdmVkIGVmZmljaWVuY3kpIG9mIEwzLg0KDQo+IEJlY2F1c2UgTDEgaXMNCj4gc2ltcGxl LCBpdHMgbGVuZ3RoIGlzIGZpeGVkIHNvIGl0IGVhc3kgdG8gaW1wbGVtZW50LiBBbmQgSSB0aGlu ayAyLWJ5dGUNCj4gaXMgZW5vdWdoIGluIG1vc3QgY2FzZXMuIElmIDItYnl0ZSBpcyBub3QgZW5v dWdoLCA0LWJ5dGUgc3RpbGwgY2FuIGJlDQo+IG5vdCBlbm91Z2ggaW4gdGhlb3J5LiBCZXNpZGVz LCB3ZSBoYXMgYmxvY2sgcHJvdG9jb2wgdG8gZGVhbCB0aGUgZXh0cmVtZQ0KPiBjYXNlLiA6KQ0K DQpFeGFjdGx5IQ0KVGhlc2UgYXJlIHByZXR0eSBtdWNoIHRoZSB0aG91Z2h0IHByb2Nlc3NlcyB0 aGF0IGxlZCB0byB0aGlzIHJlc3VsdC4NCg0KPiBzbyBpZiBMMSBzY2hlbWUgaXMgdGhlIG9ubHkg dmFsaWQgc2NoZW1lPw0KDQpZZXMsIHRoYXQgaXMgdGhlIG91dGNvbWUgb2YgdGhlIGNvbnNlbnN1 cyBwcm9jZXNzLg0KDQpUaGFua3MgYWdhaW4gZm9yIHJlYWNoaW5nIG91dCBhbmQgbm90aWZ5aW5n IHVzIG9mIHRoaXMgb3ZlcnNpZ2h0Lg0KDQpHcsO8w59lLCBDYXJzdGVuDQo= --_000_C6223E7F04FAF9418F0C162994D4E8339AE621szxeml513mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0 YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1p bHk65a6L5L2TO30NCnNwYW4ubWFpbC1mb290ZXINCgl7bXNvLXN0eWxlLW5hbWU6bWFpbC1mb290 ZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJ Zm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSwgQm9ybWFubjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBxdWljayB1cGRhdGluZyB0 byAtMDEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgdGhpbmsgYSBjbGVhciB1bmlmb3JtIHNjaGVtZShMMSBvbmx5KSBjb3Vs ZCBncmVhdGx5IGltcHJvdmUgdGhlIGNvbXBhdGliaWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQgaW1w bGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHNpbXBsZSA0LWJ5dGUgVENQLUNv QVAgcGFja2V0IGhlYWQgd2hvc2UgbGVuZ3RoIGlzIHNhbWUgdG8gVURQLUNvQVAgcmVhbGx5IGxv b2tzIGdvb2QsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+ZXNwZWNpYWxseSB3aGVuIENvQVAgc3RhY2sgd2lsbCBpbXBsZW1l bnQgdG8gYmUgYSBkdWFsIHN0YWNrLCB3aG8gc3VwcG9ydHMgYm90aCBvdmVyIFVEUCBhbmQgb3Zl ciBUQ1Agc2ltdWx0YW5lb3VzbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd2lsbCBtb2RpZnkgb3VyIGltcGxlbWVudGF0 aW9uIGZyb20gTDMgdG8gTDEgdG9vLCBmb2xsb3dpbmcgdGhpcyB1cGRhdGVkIGRyYWZ0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBpZD0ib3JpZ2luYWwtY29udGVu dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RmluYWxseSwgc29y cnkgdGhhdCBJIGhhdmUgdXNlZCBteSBwcml2YXRlIGVtYWlsIGFuZCBhbiBlbXB0eSBuYW1lIHBy ZXZpb3VzbHksIG15IG5hbWUgaXMgWmhlbmcgRmVpLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyBhZ2Fpbi48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQiPi0tLS0t LS0tLS0tLS0tLS0tLQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQiPuWOn+Wn i+mCruS7tjxzcGFuIGxhbmc9IkVOLVVTIj4gLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjBGMEYwIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2NvbG9yOiMyMTIxMjEiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu Pjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29s b3I6IzIxMjEyMSI+IENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHpp Lm9yZyI+Y2Fib0B0emkub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjBGMEYwIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOiMyMTIxMjEiPuWPkemAgeaXtumX tDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6IzIxMjEyMSI+IDIwMTU8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjojMjEyMTIxIj7lubQ8c3BhbiBsYW5nPSJFTi1V UyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIwPC9zcGFuPuaXpTxzcGFuIGxhbmc9 IkVOLVVTIj4NCiAwMToxMzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRjBGMEYwIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOiMyMTIxMjEiPuaUtuS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Y29sb3I6IzIxMjEyMSI+IDc3NDE2MyAmbHQ7PGEgaHJlZj0ibWFp bHRvOjc3NDE2M0BxcS5jb20iPjc3NDE2M0BxcS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOiNGMEYwRjAiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6IzIxMjEy MSI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtjb2xvcjojMjEyMTIxIj4gc2xlbWF5ICZs dDs8YSBocmVmPSJtYWlsdG86c2xlbWF5QHplYnJhLmNvbSI+c2xlbWF5QHplYnJhLmNvbTwvYT4m Z3Q7LA0KIHZzb2xvcnphbm9iYXJib3phICZsdDs8YSBocmVmPSJtYWlsdG86dnNvbG9yemFub2Jh cmJvemFAemVicmEuY29tIj52c29sb3J6YW5vYmFyYm96YUB6ZWJyYS5jb208L2E+Jmd0OywgSGFu bmVzLnRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpIYW5uZXMudHNjaG9mZW5pZ0BnbXgu bmV0Ij5IYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDojRjBGMEYwIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2NvbG9yOiMyMTIxMjEi PuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6IzIxMjEyMSI+IFJlOiBhIHF1ZXN0 aW9uIGFib3V0IHRoZSBNZXNzYWdlIEZvcm1hdCBpbiBkcmFmdC10c2Nob2ZlbmlnLWNvcmUtY29h cC10Y3AtdGxzLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCkhpIDc3NDE2 Myw8YnI+DQo8YnI+DQooaG93IGRvIHlvdSBwcm9ub3VuY2UgeW91ciBuYW1lPyA6LSk8YnI+DQo8 YnI+DQomZ3Q7IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBsYXRlc3QgZG9jdW1lbnQgbm93 Ljxicj4NCiZndDsgQWJvdXQgdGhlIE1lc3NhZ2UgRm9ybWF0LCBJbiBzZWN0aW9uIDQsIEkgY2Fu IHNlZSB0aGF0IHlvdSBjaG9vc2UgdGhlIEwxPGJyPg0KJmd0OyBzY2hlbWUsIGFuZCBubyBvdGhl ciBzY2hlbWVzIGFyZSBtZW50aW9uZWQsIHNvIGlmIEkgY2FuIGRyYXcgY29uY2x1c2lvbjxicj4N CiZndDsgdGhhdCBMMSBpcyB0aGUgZHJhZnQgc3RhbmRhcmQsIGFuZCBvdGhlciBzY2hlbWVzIGFy ZSBObyBsb25nZXIgd2l0aGluPGJyPg0KJmd0OyB0aGUgc2NvcGUgb2YgdGhlIGNvbnNpZGVyYXRp b24/PGJyPg0KPGJyPg0KVGhhdCBpcyB0aGUgcmVzdWx0IG9mIHRoZSBZb2tvaGFtYSBtZWV0aW5n IGFuZCB0aGUgY29uc2Vuc3VzIGNhbGwgd2UgaGFkPGJyPg0KYWZ0ZXIgdGhhdC48YnI+DQo8YnI+ DQomZ3Q7IEJ1dCBpbiBzZWN0aW9uIDMgLS0mZ3Q7ICZxdW90O3VubGVzcyBhbHRlcm5hdGl2ZSBM MyBiZWxvdyBpcyBjaG9zZW4mcXVvdDs8YnI+DQomZ3Q7IEl0IHNlZW1zIHRoYXQgb3RoZXIgc2No ZW1lcyBhcmUgc3RpbGwgdmFsaWQ/IEknbSByZWFsbHkgY29uZnVzZWQgYWJvdXQgdGhpcy48YnI+ DQo8YnI+DQpPb3BzLjxicj4NCjxicj4NCkZhaWxpbmcgdG8gcmVtb3ZlIHRoaXMgcmVtbmFudCB3 YXMgbXkgZWRpdG9yaWFsIG92ZXJzaWdodC48YnI+DQpUaGFuayB5b3UgZm9yIGFsZXJ0aW5nIHVz LiZuYnNwOyBJIGp1c3Qgc3VibWl0dGVkIGFuIHVwZGF0ZSwgLTAxLCB0byByZW1vdmU8YnI+DQp0 aGlzIGNvbmZ1c2luZyBwYXNzYWdlLjxicj4NCjxicj4NCiZndDsgSSB0aGluayBtb3N0IHVzZXJz IGFyZSBoZXNpdGF0aW5nIGJldHdlZW4gTDEgYW5kIEwzLiBBY3R1YWxseSB3ZSBoYXZlPGJyPg0K Jmd0OyBpbXBsZW1lbnQgdGhlIEwzIHNjaGVtZSBidXQgSSByZWFsbHkgbGlrZSBMMSBzY2hlbWUu IDxicj4NCjxicj4NCkluZGVlZCwgdGhlIFdHIGhhcyBiZWVuIGhlc2l0YXRpbmcgYSB3aGlsZSBh cyB3ZWxsLjxicj4NCkluIHRoZSBlbmQsIHRoZSBzaW1wbGljaXR5IG9mIEwxIHdvbiBvdmVyIHRo ZSBnZW5lcmFsaXR5IChhbmQgc2xpZ2h0bHk8YnI+DQppbXByb3ZlZCBlZmZpY2llbmN5KSBvZiBM My48YnI+DQo8YnI+DQomZ3Q7IEJlY2F1c2UgTDEgaXM8YnI+DQomZ3Q7IHNpbXBsZSwgaXRzIGxl bmd0aCBpcyBmaXhlZCBzbyBpdCBlYXN5IHRvIGltcGxlbWVudC4gQW5kIEkgdGhpbmsgMi1ieXRl PGJyPg0KJmd0OyBpcyBlbm91Z2ggaW4gbW9zdCBjYXNlcy4gSWYgMi1ieXRlIGlzIG5vdCBlbm91 Z2gsIDQtYnl0ZSBzdGlsbCBjYW4gYmU8YnI+DQomZ3Q7IG5vdCBlbm91Z2ggaW4gdGhlb3J5LiBC ZXNpZGVzLCB3ZSBoYXMgYmxvY2sgcHJvdG9jb2wgdG8gZGVhbCB0aGUgZXh0cmVtZTxicj4NCiZn dDsgY2FzZS4gOik8YnI+DQo8YnI+DQpFeGFjdGx5ITxicj4NClRoZXNlIGFyZSBwcmV0dHkgbXVj aCB0aGUgdGhvdWdodCBwcm9jZXNzZXMgdGhhdCBsZWQgdG8gdGhpcyByZXN1bHQuPGJyPg0KPGJy Pg0KJmd0OyBzbyBpZiBMMSBzY2hlbWUgaXMgdGhlIG9ubHkgdmFsaWQgc2NoZW1lPzxicj4NCjxi cj4NClllcywgdGhhdCBpcyB0aGUgb3V0Y29tZSBvZiB0aGUgY29uc2Vuc3VzIHByb2Nlc3MuPGJy Pg0KPGJyPg0KVGhhbmtzIGFnYWluIGZvciByZWFjaGluZyBvdXQgYW5kIG5vdGlmeWluZyB1cyBv ZiB0aGlzIG92ZXJzaWdodC48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C6223E7F04FAF9418F0C162994D4E8339AE621szxeml513mbxchina_-- From nobody Mon Nov 23 00:58:10 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F27D1B3860 for ; Mon, 23 Nov 2015 00:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcLh4slOUig4 for ; Mon, 23 Nov 2015 00:58:05 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6711B3856 for ; Mon, 23 Nov 2015 00:58:05 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud6.xs4all.net with ESMTP id kwy11r00Z4K0fSy01wy13F; Mon, 23 Nov 2015 09:58:02 +0100 Received: from [2001:983:a264:1:9df4:60b8:396e:73f] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 23 Nov 2015 09:58:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 23 Nov 2015 09:58:01 +0100 From: peter van der Stok To: Michel Veillette Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (3qJxpUVx58iC6eUVL1rVXFcwCA87x6CW) User-Agent: XS4ALL Webmail Archived-At: Cc: ana@ackl.io, Core Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 23 Nov 2015 08:58:09 -0000 Hi Michel, the point is to express in the payload the replacement criteria independent of application. It is a CBOR extension to the patch format of RFC 7396. The latter allows the replacement of complete arrays, not a subset of the array. Peter Michel Veillette schreef op 2015-11-20 21:41: > Reference: YANG list to CBOR mapping > https://core-wg.github.io/yang-cbor/#rfc.section.3.1.17 > > Hi Peter > > Your proposed solution for lists have some drawbacks and I'll like to > understand better its advantages to evaluate the PROS and CONS. > > List of CONS > - Your proposed solution is not aligned with > draft-ietf-netmod-yang-json-06 > - Your proposed solution take one extra byte per list entry > - Your proposed solution use a map as key for a map, which is uncommon > (Illegal in JSON but not in CBOR) > - The encoding of list defined with keys or without keys are done > differently > > CoMI-CoOL clients and servers known which data nodes of a list are > keys and which ones are associated information. > I don鈥檛 the see value of implementing the keys on the left side of the > ':' (key) and the rest of the data nodes on the right side of the ':" > (value). > This semantic is already known by both ends, why we need to add it to > the encoding? > > === Examples > > Map of map solution with CoMI IDs (88 Bytes) > { > 11111111 : { > {22222222 : "book1", 33333333 : "author2"} : {44444444 : 500, > 55555555: 66} , > {22222222 : "book5", 33333333 : "author3"} : {44444444 : 444, > 55555555: 11} > } > } > > Array of map solution with CoMI IDs (86 Bytes) > { > 11111111 : [ > { > 22222222 : "book1", > 33333333 : "author2", > 44444444 : 500, > 55555555: 66 > } , > { > 22222222 : "book5", > 33333333 : "author3", > 44444444 : 444, > 55555555: 11 > } > ] > } > > Map of map solution with CoOL IDs (56 Bytes) > > { > 11111111 : { > {2 : "book1", 3 : "author2"} : {4 : 500, 5: 66} , > {2 : "book5", 3 : "author3"} : {4 : 444, 5: 11} > } > } > > Array of map solution with CoOL IDs (54 Bytes) > > { > 11111111 : [ > { > 2 : "book1", > 3 : "author2", > 4 : 500, > 5: 66 > } , > { > 2 : "book5", > 3 : "author3", > 4 : 444, > 5: 11 > } > ] > } > > You say "It is the wish to transport only those list elements with a > unique key value, either to support a PATCH or a FETCH command". > I don鈥檛 see why this is not the case for both representations. > > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veillette@trilliantinc.com > www.trilliantinc.com 聽 > > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der > Stok > Sent: November-19-15 5:06 AM > To: Core > Cc: lhotka@nic.cz > Subject: [core] YANG list to CBOR mapping > > Hi CoOL authors, > > This e_mail complements my earlier e-mail on YANG to CBOR mapping, and > explains the proposed list encoding. > > Both the draft yang-json and the CoOL draft encode a list as an array. > In the yang-json case as a JSON array, and in the CoOL case as major > type 4 of major type 5 objects. > This encoding prevents the selection of list instances on the basis of > the key values from the payload alone. In CoMI the list is encoded as > a major type 5 of major type 5 objects. This deviation from the > yang-json mapping is motivated by the wish to transport individual > list instances and identify the instances in the payload from the key > values. This is especially important in case of PATCH operation on > list instances. > Two cases are to be looked at: (1) the list definition specifies one > or more key elements, and (2) the list definition does not specify a > key element. We will start with a list containing key elements. > It is the wish to transport only those list elements with a unique key > value, either to support a PATCH or a FETCH command. Therefore it is > required that the payload allows the selection and identification of > these list element on the basis of their key values. Using the > diagnostic JSON notation used for CBOR diagnostics, the payload > containing a number of elements with key values should look like a > JSON object with the structure list-name: {key: value}. Both key and > value are composed of JSON objects separated by commas. For example > consider the following YANG list specification: > module foo { > namespace http://example.com/book; > prefix 鈥渇o鈥; > revision 2015-06-07; > > list B { > key 鈥渒ey1 key2鈥; > leaf key1 {type string;} > leaf key2 {type string;} > leaf coll {type int32;} > leaf counter {type int32;} > } > } > > Consider the transport of two instances specified by <鈥渒ey1鈥 = > 鈥渂ook1鈥, 鈥渒ey2鈥 = 鈥渁uthor2鈥> and by <鈥渒ey1鈥 = 鈥渂ook5鈥, 鈥渒ey2鈥 = > 鈥渁uthor3鈥> out of a larger set of instances. The representation is > different from the yang-json one for the reasons explained above. > > The payload will look like: > {"B" :{ > {"key1" : "book1", "key2" : "author2"} : > {"coll" : 500, "counter": 66} , > {"key1" : "book5", "key2" : "author3"} : > {"coll" : 444, "counter": 11} > } > } > > > Which translated to CBOR yields: > > a1 # map(1) > 61 # text(1) > 42 # "B" > a2 # map(2) > a2 # map(2) > 64 # text(4) > 6b657931 # "key1" > 65 # text(5) > 626f6f6b31 # "book1" > 64 # text(4) > 6b657932 # "key2" > 67 # text(7) > 617574686f7232 # "author2" > a2 # map(2) > 64 # text(4) > 636f6c6c # "coll" > 19 01f4 # unsigned(500) > 67 # text(7) > 636f756e746572 # "counter" > 18 42 # unsigned(66) > a2 # map(2) > 64 # text(4) > 6b657931 # "key1" > 65 # text(5) > 626f6f6b35 # "book5" > 64 # text(4) > 6b657932 # "key2" > 67 # text(7) > 617574686f7233 # "author3" > a2 # map(2) > 64 # text(4) > 636f6c6c # "coll" > 19 01bc # unsigned(444) > 67 # text(7) > 636f756e746572 # "counter" > 0b # unsigned(11) > > The corresponding yang-json draft encoding - that allows transport of > a selection of instances- does not specify the key fields and would > have looked like: > > {"B" : [ > {"key1" : "book1", > "key2" : "author2鈥, > "coll" : 500, > "counter": 66 > } , > {"key1" : "book5", > "key2" : "author3", > "coll" : 444, > "counter": 11, > } > ] > } > > Suppose there are no key elements specified. In that case it is > impossible to specify the wanted list elements, and always the whole > list must be transported. In the case of a list without key > specification is is best to use major type 4 composed of major type 5 > to transport the list, as is specified in yang-json draft. > > Consider the following YANG list > > Module foo{ > Namespace http://example.com/book; > Prefix 鈥渂o鈥 > Revision 2015-06-7 > List B { > Leaf title {type string;} > Leaf author {type string;} > Leaf coll {type int32} > Leaf counter {type int32} > } > } > > Suppose the list contains two elements. The transport payload of the > two elements looks like: > > {"B" :[ > {"title" : "book1", "author" : "author2", "coll" : 500, "counter": > 66} , > {"title" : "book5", "author" : "author3", 鈥渃oll" : 444, > "counter": > 11} > ] > } > > This payload is identical to the yang-json payload. > Which yields the corresponding CBOR code. > > a1 # map(1) > 61 # text(1) > 42 # "B" > 82 # array(2) > a4 # map(4) > 65 # text(5) > 7469746c65 # "title" > 65 # text(5) > 626f6f6b31 # "book1" > 66 # text(6) > 617574686f72 # "author" > 67 # text(7) > 617574686f7232 # "author2" > 64 # text(4) > 636f6c6c # "coll" > 19 01f4 # unsigned(500) > 67 # text(7) > 636f756e746572 # "counter" > 18 42 # unsigned(66) > a4 # map(4) > 65 # text(5) > 7469746c65 # "title" > 65 # text(5) > 626f6f6b35 # "book5" > 66 # text(6) > 617574686f72 # "author" > 67 # text(7) > 617574686f7233 # "author3" > 64 # text(4) > 636f6c6c # "coll" > 19 01bc # unsigned(444) > 67 # text(7) > 636f756e746572 # "counter" > 0b # unsigned(11) > > > -- > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Nov 23 08:16:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033C21A89EB for ; Mon, 23 Nov 2015 08:16:47 -0800 (PST) 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFClv8NhjAq7 for ; Mon, 23 Nov 2015 08:16:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDE01A89ED for ; Mon, 23 Nov 2015 08:16:42 -0800 (PST) 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.331.20; Mon, 23 Nov 2015 16:16:24 +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.0331.019; Mon, 23 Nov 2015 16:16:24 +0000 From: Michel Veillette To: "consultancy@vanderstok.org" Thread-Topic: [core] YANG list to CBOR mapping Thread-Index: AQHRIrIaNU9q4tL9iE+AdF+qow8vM56lToLAgAQGNoCAAHb+YA== Date: Mon, 23 Nov 2015 16:16:24 +0000 Message-ID: References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 5:DhYHWzv7XIkJM1tRP2umVrxFLuaBtbwBIFfNfkeq70saUv+fAPtJeDHxY0RtN5y8Ljt0u16pk5rhgCO5xOCAmGQr3FZf6GwVlfeVaYzOU8/gt5EEErKMffhfBgXiDH3K9zN/4JG5puVFqDJPsDKIQQ==; 24:f498x3H4VfLGowcM5mcb+FLG9XgrTw+KtuSNSB314N/z1tZz3VHL7OYVOdudy6FpgrkEqD4XXVC9f4kwP9oh1GqmPzG0lBX9tkPdGLF0rkU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB1763; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(256376046250027)(262738631018165); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1763; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(377424004)(38414003)(199003)(189002)(40100003)(5008740100001)(5007970100001)(19580395003)(19580405001)(586003)(50986999)(99286002)(6116002)(106116001)(86362001)(105586002)(2351001)(106356001)(87936001)(101416001)(76176999)(54356999)(15975445007)(77096005)(4001150100001)(3846002)(74316001)(102836003)(2900100001)(5001960100002)(5002640100001)(92566002)(2501003)(110136002)(5003600100002)(97736004)(66066001)(76576001)(2950100001)(15395725005)(10400500002)(15974865002)(11100500001)(5004730100002)(33656002)(122556002)(81156007)(189998001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1763.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1: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: 23 Nov 2015 16:16:24.4037 (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: "ana@ackl.io" , Core Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 16:16:47 -0000 SGkgUGV0ZXINCg0KSGF2ZSB5b3UgZGVmaW5lZCBhbiBNZXJnZVBhdGNoKCkgZnVuY3Rpb24gc2lt aWxhciB0byBSRkMgNzM5NiBzZWN0aW9uIDIgZm9yIHlvdXIgcHJvcG9zZWQgZXh0ZW5zaW9uPw0K RG8gd2UgaW50ZW50IHRvIHN1cHBvcnQgdHdvIFBBVENIIGFwcHJvYWNoZXMsIFJGQyA3Mzk2IHN0 eWxlIGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaCBzdHlsZT8NCklGIHNvLCB3aHkg bGlzdCBuZWVkIHRvIGJlIHN1cHBvcnRlZCBieSB0aGUgUkZDIDczOTYgc3R5bGUgc2luY2UgdGhp cyBhcHByb2FjaCBwcm92aWRlIGEgcGFydGlhbCBjb3ZlcmFnZSAobGlzdCB3aXRob3V0IGtleXMg YW5kIHVzZXIgb3JkZXJlZCBsaXN0IGlzIG5vdCBmdWxseSBzdXBwb3J0ZWQpID8gU2hvdWxkIHdl IGFkZHJlc3MgbGlzdCBvbmx5IGluIHRoZSBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaCBz dHlsZT8NCg0KTWljaGVsIFZlaWxsZXR0ZQ0KU3lzdGVtIEFyY2hpdGVjdHVyZSBEaXJlY3Rvcg0K VHJpbGxpYW50IEluYy4NClRlbDogNDUwLTM3NS0wNTU2IGV4dC4gMjM3DQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tj b25zQHhzNGFsbC5ubF0gDQpTZW50OiBOb3ZlbWJlci0yMy0xNSAzOjU4IEFNDQpUbzogTWljaGVs IFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPg0KU3ViamVjdDog UkU6IFtjb3JlXSBZQU5HIGxpc3QgdG8gQ0JPUiBtYXBwaW5nDQoNCkhpIE1pY2hlbCwNCg0KdGhl IHBvaW50IGlzIHRvIGV4cHJlc3MgaW4gdGhlIHBheWxvYWQgdGhlIHJlcGxhY2VtZW50IGNyaXRl cmlhIGluZGVwZW5kZW50IG9mIGFwcGxpY2F0aW9uLg0KSXQgaXMgYSBDQk9SIGV4dGVuc2lvbiB0 byB0aGUgcGF0Y2ggZm9ybWF0IG9mIFJGQyA3Mzk2Lg0KVGhlIGxhdHRlciBhbGxvd3MgdGhlIHJl cGxhY2VtZW50IG9mIGNvbXBsZXRlIGFycmF5cywgbm90IGEgc3Vic2V0IG9mIHRoZSBhcnJheS4N Cg0KUGV0ZXINCg0KTWljaGVsIFZlaWxsZXR0ZSBzY2hyZWVmIG9wIDIwMTUtMTEtMjAgMjE6NDE6 DQo+IFJlZmVyZW5jZTogWUFORyBsaXN0IHRvIENCT1IgbWFwcGluZw0KPiBodHRwczovL2NvcmUt d2cuZ2l0aHViLmlvL3lhbmctY2Jvci8jcmZjLnNlY3Rpb24uMy4xLjE3DQo+IA0KPiBIaSBQZXRl cg0KPiANCj4gWW91ciBwcm9wb3NlZCBzb2x1dGlvbiBmb3IgbGlzdHMgaGF2ZSBzb21lIGRyYXdi YWNrcyBhbmQgSSdsbCBsaWtlIHRvIA0KPiB1bmRlcnN0YW5kIGJldHRlciBpdHMgYWR2YW50YWdl cyB0byBldmFsdWF0ZSB0aGUgUFJPUyBhbmQgQ09OUy4NCj4gDQo+IExpc3Qgb2YgQ09OUw0KPiAt IFlvdXIgcHJvcG9zZWQgc29sdXRpb24gaXMgbm90IGFsaWduZWQgd2l0aA0KPiBkcmFmdC1pZXRm LW5ldG1vZC15YW5nLWpzb24tMDYNCj4gLSBZb3VyIHByb3Bvc2VkIHNvbHV0aW9uIHRha2Ugb25l IGV4dHJhIGJ5dGUgcGVyIGxpc3QgZW50cnkNCj4gLSBZb3VyIHByb3Bvc2VkIHNvbHV0aW9uIHVz ZSBhIG1hcCBhcyBrZXkgZm9yIGEgbWFwLCB3aGljaCBpcyB1bmNvbW1vbiANCj4gKElsbGVnYWwg aW4gSlNPTiBidXQgbm90IGluIENCT1IpDQo+IC0gVGhlIGVuY29kaW5nIG9mIGxpc3QgZGVmaW5l ZCB3aXRoIGtleXMgb3Igd2l0aG91dCBrZXlzIGFyZSBkb25lIA0KPiBkaWZmZXJlbnRseQ0KPiAN Cj4gQ29NSS1Db09MIGNsaWVudHMgYW5kIHNlcnZlcnMga25vd24gd2hpY2ggZGF0YSBub2RlcyBv ZiBhIGxpc3QgYXJlIA0KPiBrZXlzIGFuZCB3aGljaCBvbmVzIGFyZSBhc3NvY2lhdGVkIGluZm9y bWF0aW9uLg0KPiBJIGRvbuKAmXQgdGhlIHNlZSB2YWx1ZSBvZiBpbXBsZW1lbnRpbmcgdGhlIGtl eXMgb24gdGhlIGxlZnQgc2lkZSBvZiB0aGUgDQo+ICc6JyAoa2V5KSBhbmQgdGhlIHJlc3Qgb2Yg dGhlIGRhdGEgbm9kZXMgb24gdGhlIHJpZ2h0IHNpZGUgb2YgdGhlICc6Ig0KPiAodmFsdWUpLg0K PiBUaGlzIHNlbWFudGljIGlzIGFscmVhZHkga25vd24gYnkgYm90aCBlbmRzLCB3aHkgd2UgbmVl ZCB0byBhZGQgaXQgdG8gDQo+IHRoZSBlbmNvZGluZz8NCj4gDQo+ID09PSBFeGFtcGxlcw0KPiAN Cj4gTWFwIG9mIG1hcCBzb2x1dGlvbiB3aXRoIENvTUkgSURzICg4OCBCeXRlcykNCj4gICB7DQo+ ICAgICAxMTExMTExMSA6IHsNCj4gICAgICAgezIyMjIyMjIyIDogImJvb2sxIiwgMzMzMzMzMzMg OiAiYXV0aG9yMiJ9IDogezQ0NDQ0NDQ0IDogNTAwLA0KPiA1NTU1NTU1NTogNjZ9ICwNCj4gICAg ICAgezIyMjIyMjIyIDogImJvb2s1IiwgMzMzMzMzMzMgOiAiYXV0aG9yMyJ9IDogezQ0NDQ0NDQ0 IDogNDQ0LA0KPiA1NTU1NTU1NTogMTF9DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gQXJyYXkgb2Yg bWFwIHNvbHV0aW9uIHdpdGggQ29NSSBJRHMgKDg2IEJ5dGVzKQ0KPiAgIHsNCj4gICAgIDExMTEx MTExIDogWw0KPiAgICAgICB7DQo+ICAgICAgICAgMjIyMjIyMjIgOiAiYm9vazEiLA0KPiAgICAg ICAgIDMzMzMzMzMzIDogImF1dGhvcjIiLA0KPiAgICAgICAgIDQ0NDQ0NDQ0IDogNTAwLA0KPiAg ICAgICAgIDU1NTU1NTU1OiA2Ng0KPiAgICAgICB9ICwNCj4gICAgICAgew0KPiAgICAgICAgIDIy MjIyMjIyIDogImJvb2s1IiwNCj4gICAgICAgICAzMzMzMzMzMyA6ICJhdXRob3IzIiwNCj4gICAg ICAgICA0NDQ0NDQ0NCA6IDQ0NCwNCj4gICAgICAgICA1NTU1NTU1NTogMTENCj4gICAgICAgfQ0K PiAgICAgXQ0KPiAgIH0NCj4gDQo+IE1hcCBvZiBtYXAgc29sdXRpb24gd2l0aCBDb09MIElEcyAo NTYgQnl0ZXMpDQo+IA0KPiAgICAgew0KPiAgICAgICAxMTExMTExMSA6IHsNCj4gICAgICAgICB7 MiA6ICJib29rMSIsIDMgOiAiYXV0aG9yMiJ9IDogezQgOiA1MDAsIDU6IDY2fSAsDQo+ICAgICAg ICAgezIgOiAiYm9vazUiLCAzIDogImF1dGhvcjMifSA6IHs0IDogNDQ0LCA1OiAxMX0NCj4gICAg ICAgfQ0KPiAgICAgfQ0KPiANCj4gQXJyYXkgb2YgbWFwIHNvbHV0aW9uIHdpdGggQ29PTCBJRHMg KDU0IEJ5dGVzKQ0KPiANCj4gICAgIHsNCj4gICAgICAgMTExMTExMTEgOiBbDQo+ICAgICAgICAg ew0KPiAgICAgICAgICAgMiA6ICJib29rMSIsDQo+ICAgICAgICAgICAzIDogImF1dGhvcjIiLA0K PiAgICAgICAgICAgNCA6IDUwMCwNCj4gICAgICAgICAgIDU6IDY2DQo+ICAgICAgICAgfSAsDQo+ ICAgICAgICAgew0KPiAgICAgICAgICAgMiA6ICJib29rNSIsDQo+ICAgICAgICAgICAzIDogImF1 dGhvcjMiLA0KPiAgICAgICAgICAgNCA6IDQ0NCwNCj4gICAgICAgICAgIDU6IDExDQo+ICAgICAg ICAgfQ0KPiAgICAgICBdDQo+ICAgICB9DQo+IA0KPiBZb3Ugc2F5ICJJdCBpcyB0aGUgd2lzaCB0 byB0cmFuc3BvcnQgb25seSB0aG9zZSBsaXN0IGVsZW1lbnRzIHdpdGggYSANCj4gdW5pcXVlIGtl eSB2YWx1ZSwgZWl0aGVyIHRvIHN1cHBvcnQgYSBQQVRDSCBvciBhIEZFVENIIGNvbW1hbmQiLg0K PiBJIGRvbuKAmXQgc2VlIHdoeSB0aGlzIGlzIG5vdCB0aGUgY2FzZSBmb3IgYm90aCByZXByZXNl bnRhdGlvbnMuDQo+IA0KPiBNaWNoZWwgVmVpbGxldHRlDQo+IFN5c3RlbSBBcmNoaXRlY3R1cmUg RGlyZWN0b3INCj4gVHJpbGxpYW50IEluYy4NCj4gVGVsOiA0NTAtMzc1LTA1NTYgZXh0LiAyMzcN Cj4gbWljaGVsLnZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tDQo+IHd3dy50cmlsbGlhbnRpbmMu Y29tDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29yZSBb bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBldGVyIHZhbiBkZXIg DQo+IFN0b2sNCj4gU2VudDogTm92ZW1iZXItMTktMTUgNTowNiBBTQ0KPiBUbzogQ29yZSA8Y29y ZUBpZXRmLm9yZz4NCj4gQ2M6IGxob3RrYUBuaWMuY3oNCj4gU3ViamVjdDogW2NvcmVdIFlBTkcg bGlzdCB0byBDQk9SIG1hcHBpbmcNCj4gDQo+IEhpIENvT0wgYXV0aG9ycywNCj4gDQo+IFRoaXMg ZV9tYWlsIGNvbXBsZW1lbnRzIG15IGVhcmxpZXIgZS1tYWlsIG9uIFlBTkcgdG8gQ0JPUiBtYXBw aW5nLCBhbmQgDQo+IGV4cGxhaW5zIHRoZSBwcm9wb3NlZCBsaXN0IGVuY29kaW5nLg0KPiANCj4g Qm90aCB0aGUgZHJhZnQgeWFuZy1qc29uIGFuZCB0aGUgQ29PTCBkcmFmdCBlbmNvZGUgYSBsaXN0 IGFzIGFuIGFycmF5Lg0KPiBJbiB0aGUgeWFuZy1qc29uIGNhc2UgYXMgYSBKU09OIGFycmF5LCBh bmQgaW4gdGhlIENvT0wgY2FzZSBhcyBtYWpvciANCj4gdHlwZSA0IG9mIG1ham9yIHR5cGUgNSBv YmplY3RzLg0KPiBUaGlzIGVuY29kaW5nIHByZXZlbnRzIHRoZSBzZWxlY3Rpb24gb2YgbGlzdCBp bnN0YW5jZXMgb24gdGhlIGJhc2lzIG9mIA0KPiB0aGUga2V5IHZhbHVlcyBmcm9tIHRoZSBwYXls b2FkIGFsb25lLiBJbiBDb01JIHRoZSBsaXN0IGlzIGVuY29kZWQgYXMgDQo+IGEgbWFqb3IgdHlw ZSA1IG9mIG1ham9yIHR5cGUgNSBvYmplY3RzLiBUaGlzIGRldmlhdGlvbiBmcm9tIHRoZSANCj4g eWFuZy1qc29uIG1hcHBpbmcgaXMgbW90aXZhdGVkIGJ5IHRoZSB3aXNoIHRvIHRyYW5zcG9ydCBp bmRpdmlkdWFsIA0KPiBsaXN0IGluc3RhbmNlcyBhbmQgaWRlbnRpZnkgdGhlIGluc3RhbmNlcyBp biB0aGUgcGF5bG9hZCBmcm9tIHRoZSBrZXkgDQo+IHZhbHVlcy4gVGhpcyBpcyBlc3BlY2lhbGx5 IGltcG9ydGFudCBpbiBjYXNlIG9mIFBBVENIIG9wZXJhdGlvbiBvbiANCj4gbGlzdCBpbnN0YW5j ZXMuDQo+IFR3byBjYXNlcyBhcmUgdG8gYmUgbG9va2VkIGF0OiAoMSkgdGhlIGxpc3QgZGVmaW5p dGlvbiBzcGVjaWZpZXMgb25lIA0KPiBvciBtb3JlIGtleSBlbGVtZW50cywgYW5kICgyKSB0aGUg bGlzdCBkZWZpbml0aW9uIGRvZXMgbm90IHNwZWNpZnkgYSANCj4ga2V5IGVsZW1lbnQuIFdlIHdp bGwgc3RhcnQgd2l0aCBhIGxpc3QgY29udGFpbmluZyBrZXkgZWxlbWVudHMuDQo+IEl0IGlzIHRo ZSB3aXNoIHRvIHRyYW5zcG9ydCBvbmx5IHRob3NlIGxpc3QgZWxlbWVudHMgd2l0aCBhIHVuaXF1 ZSBrZXkgDQo+IHZhbHVlLCBlaXRoZXIgdG8gc3VwcG9ydCBhIFBBVENIIG9yIGEgRkVUQ0ggY29t bWFuZC4gVGhlcmVmb3JlIGl0IGlzIA0KPiByZXF1aXJlZCB0aGF0IHRoZSBwYXlsb2FkIGFsbG93 cyB0aGUgc2VsZWN0aW9uIGFuZCBpZGVudGlmaWNhdGlvbiBvZiANCj4gdGhlc2UgbGlzdCBlbGVt ZW50IG9uIHRoZSBiYXNpcyBvZiB0aGVpciBrZXkgdmFsdWVzLiBVc2luZyB0aGUgDQo+IGRpYWdu b3N0aWMgSlNPTiBub3RhdGlvbiB1c2VkIGZvciBDQk9SIGRpYWdub3N0aWNzLCB0aGUgcGF5bG9h ZCANCj4gY29udGFpbmluZyBhIG51bWJlciBvZiBlbGVtZW50cyB3aXRoIGtleSB2YWx1ZXMgc2hv dWxkIGxvb2sgbGlrZSBhIA0KPiBKU09OIG9iamVjdCB3aXRoIHRoZSBzdHJ1Y3R1cmUgbGlzdC1u YW1lOiB7a2V5OiB2YWx1ZX0uIEJvdGgga2V5IGFuZCANCj4gdmFsdWUgYXJlIGNvbXBvc2VkIG9m IEpTT04gb2JqZWN0cyBzZXBhcmF0ZWQgYnkgY29tbWFzLiBGb3IgZXhhbXBsZSANCj4gY29uc2lk ZXIgdGhlIGZvbGxvd2luZyBZQU5HIGxpc3Qgc3BlY2lmaWNhdGlvbjoNCj4gbW9kdWxlIGZvbyB7 DQo+ICAgICAgbmFtZXNwYWNlIGh0dHA6Ly9leGFtcGxlLmNvbS9ib29rOw0KPiAgICAgIHByZWZp eCDigJxmb+KAnTsNCj4gICAgICByZXZpc2lvbiAgMjAxNS0wNi0wNzsNCj4gDQo+ICAgICBsaXN0 IEIgew0KPiAgICAgICAga2V5IOKAnGtleTEga2V5MuKAnTsNCj4gICAgICAgIGxlYWYga2V5MSB7 dHlwZSBzdHJpbmc7fQ0KPiAgICAgICAgbGVhZiBrZXkyIHt0eXBlIHN0cmluZzt9DQo+ICAgICAg ICBsZWFmIGNvbGwge3R5cGUgaW50MzI7fQ0KPiAgICAgICAgbGVhZiBjb3VudGVyIHt0eXBlIGlu dDMyO30NCj4gICAgIH0NCj4gfQ0KPiANCj4gQ29uc2lkZXIgdGhlIHRyYW5zcG9ydCBvZiB0d28g aW5zdGFuY2VzIHNwZWNpZmllZCBieSA84oCca2V5MeKAnSA9IA0KPiDigJxib29rMeKAnSwg4oCc a2V5MuKAnSA9IOKAnGF1dGhvcjLigJ0+IGFuZCBieSA84oCca2V5MeKAnSA9IOKAnGJvb2s14oCd LCDigJxrZXky4oCdID0gDQo+IOKAnGF1dGhvcjPigJ0+IG91dCBvZiBhIGxhcmdlciBzZXQgb2Yg aW5zdGFuY2VzLiBUaGUgcmVwcmVzZW50YXRpb24gaXMgDQo+IGRpZmZlcmVudCBmcm9tIHRoZSB5 YW5nLWpzb24gb25lIGZvciB0aGUgcmVhc29ucyBleHBsYWluZWQgYWJvdmUuDQo+IA0KPiBUaGUg cGF5bG9hZCB3aWxsIGxvb2sgbGlrZToNCj4geyJCIiA6ew0KPiAgICAgIHsia2V5MSIgOiAiYm9v azEiLCAia2V5MiIgOiAiYXV0aG9yMiJ9IDoNCj4gICAgICB7ImNvbGwiIDogNTAwLCAiY291bnRl ciI6IDY2fSAsDQo+ICAgICAgeyJrZXkxIiA6ICJib29rNSIsICJrZXkyIiA6ICJhdXRob3IzIn0g Og0KPiAgICAgIHsiY29sbCIgOiA0NDQsICJjb3VudGVyIjogMTF9DQo+ICAgICAgfQ0KPiB9DQo+ IA0KPiANCj4gV2hpY2ggdHJhbnNsYXRlZCB0byBDQk9SIHlpZWxkczoNCj4gDQo+IGExICAgICAg ICAgICAgICAgICAgICAgICAgICMgbWFwKDEpDQo+ICAgICA2MSAgICAgICAgICAgICAgICAgICAg ICAjIHRleHQoMSkNCj4gICAgICAgIDQyICAgICAgICAgICAgICAgICAgICMgIkIiDQo+ICAgICBh MiAgICAgICAgICAgICAgICAgICAgICAjIG1hcCgyKQ0KPiAgICAgICAgYTIgICAgICAgICAgICAg ICAgICAgIyBtYXAoMikNCj4gICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4dCg0KQ0K PiAgICAgICAgICAgICAgNmI2NTc5MzEgICAgICAgIyAia2V5MSINCj4gICAgICAgICAgIDY1ICAg ICAgICAgICAgICAgICMgdGV4dCg1KQ0KPiAgICAgICAgICAgICAgNjI2ZjZmNmIzMSAgICAgIyAi Ym9vazEiDQo+ICAgICAgICAgICA2NCAgICAgICAgICAgICAgICAjIHRleHQoNCkNCj4gICAgICAg ICAgICAgIDZiNjU3OTMyICAgICAgICMgImtleTIiDQo+ICAgICAgICAgICA2NyAgICAgICAgICAg ICAgICAjIHRleHQoNykNCj4gICAgICAgICAgICAgIDYxNzU3NDY4NmY3MjMyICMgImF1dGhvcjIi DQo+ICAgICAgICBhMiAgICAgICAgICAgICAgICAgICAjIG1hcCgyKQ0KPiAgICAgICAgICAgNjQg ICAgICAgICAgICAgICAgIyB0ZXh0KDQpDQo+ICAgICAgICAgICAgICA2MzZmNmM2YyAgICAgICAj ICJjb2xsIg0KPiAgICAgICAgICAgMTkgMDFmNCAgICAgICAgICAgIyB1bnNpZ25lZCg1MDApDQo+ ICAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCj4gICAgICAgICAgICAgIDYz NmY3NTZlNzQ2NTcyICMgImNvdW50ZXIiDQo+ICAgICAgICAgICAxOCA0MiAgICAgICAgICAgICAj IHVuc2lnbmVkKDY2KQ0KPiAgICAgICAgYTIgICAgICAgICAgICAgICAgICAgIyBtYXAoMikNCj4g ICAgICAgICAgIDY0ICAgICAgICAgICAgICAgICMgdGV4dCg0KQ0KPiAgICAgICAgICAgICAgNmI2 NTc5MzEgICAgICAgIyAia2V5MSINCj4gICAgICAgICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4 dCg1KQ0KPiAgICAgICAgICAgICAgNjI2ZjZmNmIzNSAgICAgIyAiYm9vazUiDQo+ICAgICAgICAg ICA2NCAgICAgICAgICAgICAgICAjIHRleHQoNCkNCj4gICAgICAgICAgICAgIDZiNjU3OTMyICAg ICAgICMgImtleTIiDQo+ICAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCj4g ICAgICAgICAgICAgIDYxNzU3NDY4NmY3MjMzICMgImF1dGhvcjMiDQo+ICAgICAgICBhMiAgICAg ICAgICAgICAgICAgICAjIG1hcCgyKQ0KPiAgICAgICAgICAgNjQgICAgICAgICAgICAgICAgIyB0 ZXh0KDQpDQo+ICAgICAgICAgICAgICA2MzZmNmM2YyAgICAgICAjICJjb2xsIg0KPiAgICAgICAg ICAgMTkgMDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQo+ICAgICAgICAgICA2NyAgICAg ICAgICAgICAgICAjIHRleHQoNykNCj4gICAgICAgICAgICAgIDYzNmY3NTZlNzQ2NTcyICMgImNv dW50ZXIiDQo+ICAgICAgICAgICAwYiAgICAgICAgICAgICAgICAjIHVuc2lnbmVkKDExKQ0KPiAN Cj4gVGhlIGNvcnJlc3BvbmRpbmcgeWFuZy1qc29uIGRyYWZ0IGVuY29kaW5nIC0gdGhhdCBhbGxv d3MgdHJhbnNwb3J0IG9mIA0KPiBhIHNlbGVjdGlvbiBvZiBpbnN0YW5jZXMtIGRvZXMgbm90IHNw ZWNpZnkgdGhlIGtleSBmaWVsZHMgYW5kIHdvdWxkIA0KPiBoYXZlIGxvb2tlZCBsaWtlOg0KPiAN Cj4geyJCIiA6IFsNCj4gICAgICB7ImtleTEiIDogImJvb2sxIiwNCj4gICAgICAgICJrZXkyIiA6 ICJhdXRob3Iy4oCdLA0KPiAgICAgICAgICJjb2xsIiA6IDUwMCwNCj4gICAgICAgICAiY291bnRl ciI6IDY2DQo+ICAgICAgIH0gLA0KPiAgICAgIHsia2V5MSIgOiAiYm9vazUiLA0KPiAgICAgICAg ImtleTIiIDogImF1dGhvcjMiLA0KPiAgICAgICAgImNvbGwiIDogNDQ0LA0KPiAgICAgICAgImNv dW50ZXIiOiAxMSwNCj4gICAgICB9DQo+ICAgIF0NCj4gfQ0KPiANCj4gU3VwcG9zZSB0aGVyZSBh cmUgbm8ga2V5IGVsZW1lbnRzIHNwZWNpZmllZC4gSW4gdGhhdCBjYXNlIGl0IGlzIA0KPiBpbXBv c3NpYmxlIHRvIHNwZWNpZnkgdGhlIHdhbnRlZCBsaXN0IGVsZW1lbnRzLCBhbmQgYWx3YXlzIHRo ZSB3aG9sZSANCj4gbGlzdCBtdXN0IGJlIHRyYW5zcG9ydGVkLiBJbiB0aGUgY2FzZSBvZiBhIGxp c3Qgd2l0aG91dCBrZXkgDQo+IHNwZWNpZmljYXRpb24gaXMgaXMgYmVzdCB0byB1c2UgbWFqb3Ig dHlwZSA0IGNvbXBvc2VkIG9mIG1ham9yIHR5cGUgNSANCj4gdG8gdHJhbnNwb3J0IHRoZSBsaXN0 LCBhcyBpcyBzcGVjaWZpZWQgaW4geWFuZy1qc29uIGRyYWZ0Lg0KPiANCj4gQ29uc2lkZXIgdGhl IGZvbGxvd2luZyBZQU5HIGxpc3QNCj4gDQo+IE1vZHVsZSBmb297DQo+ICAgICAgTmFtZXNwYWNl IGh0dHA6Ly9leGFtcGxlLmNvbS9ib29rOw0KPiAgICAgIFByZWZpeCDigJxib+KAnQ0KPiAgICAg IFJldmlzaW9uICAyMDE1LTA2LTcNCj4gTGlzdCBCIHsNCj4gICAgIExlYWYgdGl0bGUge3R5cGUg c3RyaW5nO30NCj4gICAgIExlYWYgYXV0aG9yIHt0eXBlIHN0cmluZzt9DQo+ICAgICBMZWFmIGNv bGwge3R5cGUgaW50MzJ9DQo+ICAgICBMZWFmIGNvdW50ZXIge3R5cGUgaW50MzJ9DQo+ICAgICB9 DQo+IH0NCj4gDQo+IFN1cHBvc2UgdGhlIGxpc3QgY29udGFpbnMgdHdvIGVsZW1lbnRzLiBUaGUg dHJhbnNwb3J0IHBheWxvYWQgb2YgdGhlIA0KPiB0d28gZWxlbWVudHMgbG9va3MgbGlrZToNCj4g DQo+IHsiQiIgOlsNCj4gICAgICB7InRpdGxlIiA6ICJib29rMSIsICJhdXRob3IiIDogImF1dGhv cjIiLCAiY29sbCIgOiA1MDAsICJjb3VudGVyIjoNCj4gNjZ9ICwNCj4gICAgICB7InRpdGxlIiA6 ICJib29rNSIsICJhdXRob3IiIDogImF1dGhvcjMiLCAg4oCcY29sbCIgOiA0NDQsDQo+ICJjb3Vu dGVyIjoNCj4gMTF9DQo+ICAgICAgXQ0KPiB9DQo+IA0KPiBUaGlzIHBheWxvYWQgaXMgaWRlbnRp Y2FsIHRvIHRoZSB5YW5nLWpzb24gcGF5bG9hZC4NCj4gV2hpY2ggeWllbGRzIHRoZSBjb3JyZXNw b25kaW5nIENCT1IgY29kZS4NCj4gDQo+IGExICAgICAgICAgICAgICAgICAgICAgICAgICMgbWFw KDEpDQo+ICAgICA2MSAgICAgICAgICAgICAgICAgICAgICAjIHRleHQoMSkNCj4gICAgICAgIDQy ICAgICAgICAgICAgICAgICAgICMgIkIiDQo+ICAgICA4MiAgICAgICAgICAgICAgICAgICAgICAj IGFycmF5KDIpDQo+ICAgICAgICBhNCAgICAgICAgICAgICAgICAgICAjIG1hcCg0KQ0KPiAgICAg ICAgICAgNjUgICAgICAgICAgICAgICAgIyB0ZXh0KDUpDQo+ICAgICAgICAgICAgICA3NDY5NzQ2 YzY1ICAgICAjICJ0aXRsZSINCj4gICAgICAgICAgIDY1ICAgICAgICAgICAgICAgICMgdGV4dCg1 KQ0KPiAgICAgICAgICAgICAgNjI2ZjZmNmIzMSAgICAgIyAiYm9vazEiDQo+ICAgICAgICAgICA2 NiAgICAgICAgICAgICAgICAjIHRleHQoNikNCj4gICAgICAgICAgICAgIDYxNzU3NDY4NmY3MiAg ICMgImF1dGhvciINCj4gICAgICAgICAgIDY3ICAgICAgICAgICAgICAgICMgdGV4dCg3KQ0KPiAg ICAgICAgICAgICAgNjE3NTc0Njg2ZjcyMzIgIyAiYXV0aG9yMiINCj4gICAgICAgICAgIDY0ICAg ICAgICAgICAgICAgICMgdGV4dCg0KQ0KPiAgICAgICAgICAgICAgNjM2ZjZjNmMgICAgICAgIyAi Y29sbCINCj4gICAgICAgICAgIDE5IDAxZjQgICAgICAgICAgICMgdW5zaWduZWQoNTAwKQ0KPiAg ICAgICAgICAgNjcgICAgICAgICAgICAgICAgIyB0ZXh0KDcpDQo+ICAgICAgICAgICAgICA2MzZm NzU2ZTc0NjU3MiAjICJjb3VudGVyIg0KPiAgICAgICAgICAgMTggNDIgICAgICAgICAgICAgIyB1 bnNpZ25lZCg2NikNCj4gICAgICAgIGE0ICAgICAgICAgICAgICAgICAgICMgbWFwKDQpDQo+ICAg ICAgICAgICA2NSAgICAgICAgICAgICAgICAjIHRleHQoNSkNCj4gICAgICAgICAgICAgIDc0Njk3 NDZjNjUgICAgICMgInRpdGxlIg0KPiAgICAgICAgICAgNjUgICAgICAgICAgICAgICAgIyB0ZXh0 KDUpDQo+ICAgICAgICAgICAgICA2MjZmNmY2YjM1ICAgICAjICJib29rNSINCj4gICAgICAgICAg IDY2ICAgICAgICAgICAgICAgICMgdGV4dCg2KQ0KPiAgICAgICAgICAgICAgNjE3NTc0Njg2Zjcy ICAgIyAiYXV0aG9yIg0KPiAgICAgICAgICAgNjcgICAgICAgICAgICAgICAgIyB0ZXh0KDcpDQo+ ICAgICAgICAgICAgICA2MTc1NzQ2ODZmNzIzMyAjICJhdXRob3IzIg0KPiAgICAgICAgICAgNjQg ICAgICAgICAgICAgICAgIyB0ZXh0KDQpDQo+ICAgICAgICAgICAgICA2MzZmNmM2YyAgICAgICAj ICJjb2xsIg0KPiAgICAgICAgICAgMTkgMDFiYyAgICAgICAgICAgIyB1bnNpZ25lZCg0NDQpDQo+ ICAgICAgICAgICA2NyAgICAgICAgICAgICAgICAjIHRleHQoNykNCj4gICAgICAgICAgICAgIDYz NmY3NTZlNzQ2NTcyICMgImNvdW50ZXIiDQo+ICAgICAgICAgICAwYiAgICAgICAgICAgICAgICAj IHVuc2lnbmVkKDExKQ0KPiANCj4gDQo+IC0tDQo+IFBldGVyIHZhbiBkZXIgU3Rvaw0KPiB2YW5k ZXJzdG9rIGNvbnN1bHRhbmN5DQo+IG1haWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmcN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Mon Nov 23 08:50:50 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6211A9060 for ; Mon, 23 Nov 2015 08:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IH9vnuMwQbg for ; Mon, 23 Nov 2015 08:50:45 -0800 (PST) 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 985721A905F for ; Mon, 23 Nov 2015 08:50:45 -0800 (PST) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id EF89C41C946; Mon, 23 Nov 2015 17:50:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3uNCoqeIw1K7; Mon, 23 Nov 2015 17:50:42 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 736EB41C945; Mon, 23 Nov 2015 17:50:40 +0100 (CET) Message-ID: <565343DE.3050202@tzi.org> Date: Mon, 23 Nov 2015 17:50:38 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Michel Veillette References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "ana@ackl.io" , Core Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 16:50:49 -0000 Michel Veillette wrote: > Hi Peter > > Have you defined an MergePatch() function similar to RFC 7396 section 2 for your proposed extension? AFAIK, the function defined by RFC 7396 should "just work". > Do we intent to support two PATCH approaches, RFC 7396 style and draft-ietf-netconf-yang-patch style? Good question. yang-patch seems a bit more complicated than is needed for many constrained applications. It also is not idempotent. > IF so, why list need to be supported by the RFC 7396 style since this approach provide a partial coverage (list without keys and user ordered list is not fully supported) ? Should we address list only in the draft-ietf-netconf-yang-patch style? I would expect many constrained applications to make use of maps, which typically are represented in YANG as lists with keys*). So I would prefer to be able to address these with a simple, merge-patch style update mechanism. Gr眉脽e, Carsten *) leaf-lists are a special case where updating isn't quite addressed yet by CoMI as far as I know. From nobody Tue Nov 24 03:23:35 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A871B2FC8 for ; Tue, 24 Nov 2015 03:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWdvARjncyy6 for ; Tue, 24 Nov 2015 03:23:31 -0800 (PST) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DF71B2FCA for ; Tue, 24 Nov 2015 03:23:29 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id lPPP1r00W4Hiz6i01PPP9h; Tue, 24 Nov 2015 12:23:27 +0100 Received: from [2001:983:a264:1:c0ea:4b3e:8dde:f751] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 24 Nov 2015 12:23:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 24 Nov 2015 12:23:23 +0100 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <565343DE.3050202@tzi.org> References: <170106a36217a736a4b55991c4a5cf6a@xs4all.nl> <565343DE.3050202@tzi.org> Message-ID: <0d1cccf5e1784c3e6b97155c063e0015@xs4all.nl> X-Sender: stokcons@xs4all.nl (s2F6XFB66LKGXbrGrS3yOV5W7deYLlSF) User-Agent: XS4ALL Webmail Archived-At: Cc: ana@ackl.io, Core Subject: Re: [core] YANG list to CBOR mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 11:23:33 -0000 Carsten Bormann schreef op 2015-11-23 17:50: > Michel Veillette wrote: >> Hi Peter >> >> Have you defined an MergePatch() function similar to RFC 7396 section >> 2 for your proposed extension? > > AFAIK, the function defined by RFC 7396 should "just work". "just" is the word, for example CBOR allows more identifier types. I would really like to encourage Carsten to write a CBOR-merge draft. It looks useful in more and more applications. > >> Do we intent to support two PATCH approaches, RFC 7396 style and >> draft-ietf-netconf-yang-patch style? > > Good question. yang-patch seems a bit more complicated than is needed > for many constrained applications. It also is not idempotent. Their use is also very different. The one is part of the transport format, the other is embedded in it. > >> IF so, why list need to be supported by the RFC 7396 style since this >> approach provide a partial coverage (list without keys and user >> ordered list is not fully supported) ? Should we address list only in >> the draft-ietf-netconf-yang-patch style? IMO user-ordered is orthogonal to keyed modifications. Why punish keyed lists because non-keyed lists do not provide the required handles? > > I would expect many constrained applications to make use of maps, which > typically are represented in YANG as lists with keys*). So I would > prefer to be able to address these with a simple, merge-patch style > update mechanism. so do I > > Gr眉脽e, Carsten > > *) leaf-lists are a special case where updating isn't quite addressed > yet by CoMI as far as I know. They represent the same characteristics as a JSON array. In json-merge you change all array members or none. Otherwise take refuge to the verbose RFC 6902 approach. From nobody Wed Nov 25 23:07:07 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48C41B29B1; Wed, 25 Nov 2015 23:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPMDfiFsrJlx; Wed, 25 Nov 2015 23:07:02 -0800 (PST) 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 B848A1B29AA; Wed, 25 Nov 2015 23:07:01 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-38-5656af93bfb7 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.CB.04914.39FA6565; Thu, 26 Nov 2015 08:06:59 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Thu, 26 Nov 2015 08:06:59 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "ietf@ietf.org" Thread-Topic: Last Call: (Block-wise transfers in CoAP) to Proposed Standard Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEA Date: Thu, 26 Nov 2015 07:06:57 +0000 Message-ID: References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> In-Reply-To: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <79B2126946DF18499FEA44FA77A7995C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2J7oO7k9WFhBj+nyVt8f36NxWLbxgts Fvverme2aDw0j9Hi2cb5LBbPnrcwOrB57Jx1l91jyZKfTB63X89nDmCO4rJJSc3JLEst0rdL 4Mo4cry24F14xdrDFxgbGM+EdjFyckgImEgc3zyJDcIWk7hwbz2QzcUhJHCYUeLOovcsEM5i RonDDS3sIFVsAi4SDxoeMYHYIgLKEgdm3mAFKWIW+Mkosfn2bRaQhLBAjsSLb5+AijiAinIl ls+0hqg3Aip5xwgSZhFQlWhqNAMJ8wpYSKza9xasU0jAUeLJ3SlgqzgFnCQebLvACmIzAh33 /dQasLXMAuISt57MZ4I4WkBiyZ7zzBC2qMTLx//A6kUF9CRWXm+CekxJonHJE1aQtcwCmhLr d+lDmNYSJ8+oQExUlJjS/ZAd4hpBiZMzn7BMYJSYhWTZLITmWQjNs5A0z0LSvICRdRWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYLwe3PJbdwfj6teOhxgFOBiVeHgLbMPChFgTy4orcw8x SnAwK4nwxmQDhXhTEiurUovy44tKc1KLDzFKc7AoifO2MD0IFRJITyxJzU5NLUgtgskycXBK NTCKC1V/2aPBabbxwrZPql0rj0ieCPl3kmffciXL5Lg3jpozZ0dMW/Xu94uT6v8eqvDWr+MU mJ1SeSyiet1t56sPQmaaXyvYqnErSSF/T7Feom572+x9W550B5/1comN2LXs8PusY/FnPO26 p22QcXhbHyIrq2Tws/dX2pzqZ1ZRH2e8u8lxN2OuEktxRqKhFnNRcSIA7xQkc9MCAAA= Archived-At: Cc: "draft-ietf-core-block@ietf.org" , "core-chairs@ietf.org" , "core@ietf.org" , "barryleiba@gmail.com" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 07:07:05 -0000 DQoNClRoZXJlIHdhcyBhIHRocmVhZCBvbiB0aGUgQ29SRSBXRyBtYWlsaW5nIGxpc3QgYSBjb3Vw bGUgb2YgbW9udGhzIGFnbyBvbg0KdGhlIHRvcGljIG9mIGJsb2Nrd2lzZSBhbmQgb2JqZWN0IHNl Y3VyaXR5LiBUaGUgc3RhcnRpbmcgcG9pbnQgd2FzIGENCnF1ZXN0aW9uIGlmIENvQVAgcHJveGll cyBjYW4gKHJlLSlwYXJ0aXRpb24gbWVzc2FnZXMgaW50byBibG9ja3MgYXMNCmRlZmluZWQgaW4g dGhpcyBkcmFmdCwgYW5kIHRoZSBpbXBsaWNhdGlvbnMgb24gZW5kLXRvLWVuZCBzZWN1cml0eSBi ZXR3ZWVuDQpjbGllbnQgYW5kIHNlcnZlciB0aHJvdWdoIHN1Y2ggYSBwcm94eS4gVGhlIGNvbmNs dXNpb25zIG9mIHRoYXQgZGlzY3Vzc2lvbg0KaGFzIGFuIGltcGFjdCBvbiB0aGlzIGRyYWZ0LCBi dXQgdGhlcmUgYXJlIG5vIGNvbnNpZGVyYXRpb25zIG9mIHRoaXMga2luZA0KbWFkZSBpbiB2ZXJz aW9uIC0xOC4gTW9yZSBkZXRhaWxzIGFyZSBnaXZlbiBiZWxvdywgaW5jbHVkaW5nIHNvbWUNCmFs dGVybmF0aXZlIHByb3Bvc2FscyBmb3IgaG93IHRvIGFkZHJlc3MgdGhpcy4gQXBvbG9naWVzIGZv ciB0aGUgbG9uZw0KZS1tYWlsLiANCg0KDQpCYWNrZ3JvdW5kOg0KDQpUaGVyZSBpcyBhbiBvbmdv aW5nIGRpc2N1c3Npb24gaW4gQ29SRSBhbmQgQUNFIFdHcyBzaW5jZSBhIHllYXIgb24gdGhlDQpl bmQtdG8tZW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgQ29BUCwgaS5lLiBwcm90ZWN0aW5nIHRo ZSBjb21tdW5pY2F0aW9uDQpiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZlciB0aHJvdWdoIHBy b3hpZXMuIFJGQyA3MjUyIGFuZCBvdGhlcg0Kc3BlY2lmaWNhdGlvbnMgaW4gdGhlIENvQVAgc3Vp dGUgZGVmaW5lIGEgc2V0IG9mIGxlZ2l0aW1hdGUgcHJveHkNCm9wZXJhdGlvbnMgb24gQ29BUCBt ZXNzYWdlcyB3aGljaCByZXF1aXJlcyBEVExTIHRvIGJlIHRlcm1pbmF0ZWQgYXQNCnByb3hpZXMu IFRoaXMgaW1wbGllcyB0aGF0IHRoZSBwcm94eSBoYXMgYWNjZXNzIG5vdCBvbmx5IHdpdGggdGhl IGRhdGENCnJlcXVpcmVkIGZvciBwZXJmb3JtIHRoZSBpbnRlbmRlZCBwcm94eSBvcGVyYXRpb24g YnV0IGlzIGFsc28gYWJsZSB0bw0KZWF2ZXNkcm9wIG9yIG1hbmlwdWxhdGUgYW55IHBhcnQgb2Yg dGhlIENvQVAgcGF5bG9hZCBhbmQgbWV0YWRhdGEgaW4NCnRyYW5zaXQgYmV0d2VlbiBjbGllbnQg YW5kIHNlcnZlciB3aXRob3V0IGJlaW5nIHByb3RlY3RlZCBvciBkZXRlY3RlZCBieQ0KRFRMUy4N Cg0KDQpPbmUgd2F5IHRvIG1pdGlnYXRlIHRoaXMgdGhyZWF0IGlzIHRvIGNvbXBsZW1lbnQgb3Ig cmVwbGFjZSBEVExTIHdpdGgNCmFwcGxpY2F0aW9uIGxheWVyIHByb3RlY3Rpb24gb2YgQ29BUCBw YXlsb2FkIGFuZCBtZXRhZGF0YSBiZXR3ZWVuIGNsaWVudA0KYW5kIHNlcnZlciBmb3IgdGhlIHVz ZSBjYXNlcyB3aGVyZSB0aGUgcHJveHkgc2hvdWxkIG5vdCBiZSBmdWxseSB0cnVzdGVkLg0KVGhp cyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIENvUkUgV0cgbWVldGluZ3MgZHVyaW5nIHRoZSB0 aHJlZSBsYXN0IElFVEYNCkYyRiBtZWV0aW5ncyBhbmQgdGhlcmUgYXJlIGRyYWZ0IHNvbHV0aW9u cyB1c2luZyB0aGUgbWVzc2FnZSBmb3JtYXQgYmVpbmcNCmRldmVsb3BlZCBpbiB0aGUgQ09TRSBX Ry4NCg0KDQpXaXRoIHRoZSBDT0FQIHByb3h5IG9wZXJhdGlvbnMgc3RhbmRhcmRpemVkIHNvIGZh ciBpdCBoYXMgYmVlbiBwb3NzaWJsZSB0bw0KcHJvdGVjdCB0aGUgQ29BUCBtZXNzYWdlcyBhZGVx dWF0ZWx5IHdpdGggc2VjdXJpdHkgb24gdHJhbnNwb3J0IGxheWVyLA0KYXBwbGljYXRpb24gbGF5 ZXIgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBJbiB0aGUgY2FzZSB3aGVyZSB0aGUNCmxlZ2l0 aW1hdGUgcHJveHkgb3BlcmF0aW9uIGlzIHByZWRpY3RhYmxlIGJ5IGNsaWVudCBhbmQgc2VydmVy LA0KYXBwbGljYXRpb24gbGF5ZXIgc2VjdXJpdHkgY2FuIGJlIGRlZmluZWQgdG8gYm90aCB2ZXJp ZnkgdGhhdCBubw0KaWxsZWdpdGltYXRlIGNoYW5nZXMgaGFzIGJlZW4gcGVyZm9ybWVkIGFzIHdl bGwgYXMgdmVyaWZ5aW5nIHRoZQ0KbGVnaXRpbWF0ZSBjaGFuZ2VzLiBJbiB0aGUgY2FzZSB3aGVy ZSBwcm94eSBvcGVyYXRpb25zIGFyZSBub3QgcHJlZGljdGFibGUNCuKAlCBldmVuIGlmIHRoZSBk YXRhIHRoZSBwcm94eSBpcyBvcGVyYXRpbmcgb24gY2Fubm90IGJlIHByb3RlY3RlZCDigJQgaXQg aGFzDQpzbyBmYXIgYmVlbiBwb3NzaWJsZSB0byB1c2Ugb3RoZXIgaW5mb3JtYXRpb24gZWxlbWVu dHMgdG8gcHJvdmlkZSB0aGUNCnJlcXVpcmVkIGVuZC10by1lbmQgc2VjdXJpdHkgcHJvcGVyaXRp ZXMuICBGb3IgZXhhbXBsZSwgdGhlIENvQVAgaGVhZGVyDQpmaWVsZCBUb2tlbiBtYXkgYmUgY2hh bmdlZCBieSBhIHByb3h5LCBidXQgaW5zdGVhZCBhIHRyYW5zYWN0aW9uDQppZGVudGlmaWVyIGNh biBiZSBpbnRyb2R1Y2VkIGluIHRoZSBhcHBsaWNhdGlvbiBzZWN1cml0eSB3cmFwcGVyIChDT1NF DQpoZWFkZXIpIHRvIGRlZmluZSBhIG1lc3NhZ2UgKGV4Y2hhbmdlKSBpZGVudGlmaWVyIGNvbW1v biB0byBjbGllbnQgYW5kDQpzZXJ2ZXIuDQoNCg0KQmxvY2t3aXNlOg0KDQpXaXRoIHRoZSBkZWZp bml0aW9uIG9mIGJsb2Nrd2lzZSB0cmFuc2ZlciBhcyBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdCBh DQpwcm94eSBtYXkgcGFydGl0aW9uIG9yIHJlLXBhcnRpdGlvbmluZyBhIG1lc3NhZ2UgaW50byBi bG9ja3Mgd2hlcmUgdGhlDQpzaXplIG9mIHRoZSBibG9ja3MgYXJlIGRlY2lkZWQgYnkgdGhlIHBy b3h5LiBBcyBhIGNvbnNlcXVlbmNlLCBpdCBpcyBub3QNCnBvc3NpYmxlIHRvIGludGVncml0eSBw cm90ZWN0IGluZGl2aWR1YWwgYmxvY2tzIGVuZC10by1lbmQgYmV0d2VlbiBjbGllbnQNCmFuZCBz ZXJ2ZXI6IERUTFMgZG9lcyBub3QgcHJvdGVjdCB0aGUgbWVzc2FnZSBkYXRhIHdpdGhpbiB0aGUg cHJveHksIGFuZA0KYXBwbGljYXRpb24gbGF5ZXIgaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgaW5k aXZpZHVhbCBibG9ja3MgY2Fubm90IGJlDQpwZXJmb3JtZWQgdW5sZXNzIHRoZSBwYXJ0aXRpb25p bmcgaW50byBibG9ja3MgYXMgcmVjZWl2ZWQgYnkgb25lIGVuZHBvaW50DQppcyBpZGVudGljYWwg dG8gdGhhdCBzZW50IGJ5IHRoZSBvdGhlciBlbmRwb2ludC4gSGVuY2UsIHdoZW4gQ29BUCBCbG9j aw0Kb3B0aW9ucyBhcmUgdXNlZCBhcyBkZWZpbmVkIGluIHRoaXMgZHJhZnQsIGVuZC10by1lbmQg c2VjdXJpdHkgb2YgdGhlDQppbmRpdmlkdWFsIENvQVAgcmVxdWVzdCBhbmQgcmVzcG9uc2UgYnJl YWtzIGRvd24uIEZvciBleGFtcGxlOiBhIHByb3h5IG1heQ0KYWRkQmxvY2sgb3B0aW9ucywgc2Vu ZCBhbnkgbnVtYmVyIG9mIGJsb2NrcyB3aXRoIGFueSBwYXlsb2FkIHRvIGFuDQplbmRwb2ludCB3 aXRob3V0IGJlaW5nIHBvc3NpYmxlIHRvIGRldGVjdCBvciBwcm90ZWN0IGFnYWluc3QuIEluIGNv bnRyYXN0DQp0byB0aGUgZXhpc3Rpbmcgc3RhbmRhcmRzIGluIHRoZSBDb0FQIHN1aXRlLCBpbiB0 aGlzIGNhc2UgaXQgaXMgbm90DQpwb3NzaWJsZSB0byBieXBhc3MgdGhlIGNvbnN0cnVjdGlvbiBh bmQgZGVmaW5lIGEgc2VjdXJlIGVuZC10by1lbmQgYmxvY2sNCnBhcnRpdGlvbmluZyB3aXRoIGxl c3MgdGhhbiBkaXNhYmxpbmcgYmxvY2sgcGFydGl0aW9uaW5nIGFzIHNwZWNpZmllZCBpbg0KdGhp cyBkcmFmdC4gDQoNCg0KT25lIHNvbHV0aW9uIHRvIHRoaXMgaXMgdG8gZGlzYWxsb3cgcHJveGll cyB0byByZS1wYXJ0aXRpb24gYSBtZXNzYWdlLA0KdGh1cyByZWRlZmluZSB0aGUgQmxvY2sgb3B0 aW9ucyBzdWNoIHRoYXQgdGhleSBhcmUgcG9zc2libGUgdG8gaW50ZWdyaXR5DQpwcm90ZWN0IGVu ZC10by1lbmQuICBJbnRlZ3JpdHkgcHJvdGVjdGluZyBlYWNoIGJsb2NrIGFuZCBjb3JyZXNwb25k aW5nDQpCbG9jayBvcHRpb25zIGFzIGRlZmluZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQgaGFzIGFk ZGl0aW9uYWwgYmVuZWZpdHM6IElmDQphbnkgYmxvY2sgaW4gdGhlIHNlcXVlbmNlIGZhaWxzIHZl cmlmaWNhdGlvbiwgaXQgY2FuIGJlIGluZGl2aWR1YWxseQ0KcmVxdWVzdGVkIHRvIGJlIHJlc2Vu dC4gV2hlbiBhbGwgYmxvY2tzIGhhcyBiZWVuIHZlcmlmaWVkIHRoZSBlbnRpcmUNCm1lc3NhZ2Ug aGFzIGJlZW4gdmVyaWZpZWQuICBBIHJlY2VpdmluZyBub2RlIG1heSBldmVuIHBlcmZvcm0gY2Vy dGFpbg0KYWN0aW9ucyBiYXNlZCBvbiByZWNlaXZlZCB2ZXJpZmllZCBibG9ja3MgYmVmb3JlIHRo ZSBlbnRpcmUgbWVzc2FnZSBoYXMNCmJlZW4gcmVjZWl2ZWQuDQoNCg0KSW5zdGVhZCBvZiBkZWxl Z2F0aW5nIHRvIHByb3hpZXMgdG8gcGFydGl0aW9uIGludG8gYmxvY2tzLCB0aGUgc2VuZGluZw0K ZW5kcG9pbnQgd291bGQgbmVlZCB0byBhbnRpY2lwYXRlIG9yIGdldCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgcmVsZXZhbnQNCmJsb2NrIHNpemUsIGUuZy4gdXNpbmcgYSBzaXplIGluZGljYXRpb24g aW4gdGhlIGxpbmstZm9ybWF0IGRlc2NyaXB0aW9uDQpbUkZDNjk5MF0uIEFkZGl0aW9uYWwgbWV0 aG9kcyBmb3IgYmxvY2tzaXplIGRpc2NvdmVyeSBtYXkgYWxzbyBiZSBkZWZpbmVkLg0KV2hpbGUg dGhpcyBtYXkgbm90IGJlIGFzIHNpbXBsZSBhcyBsZWF2aW5nIGl0IGVudGlyZWx5IHRvIHRoZSBw cm94eSB0bw0KZGVjaWRlLCBjb25zaWRlcmluZyB0aGUgYWRkaXRpb25hbCBzZWN1cml0eSBiZW5l Zml0cyBJIGJlbGlldmUgdGhpcyBpcyB0aGUNCnJpZ2h0IHRyYWRlIG9mZiB0byBtYWtlLg0KDQoN CkFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIGlzIHRvIHByZXZlbnQgcHJveGllcyBmcm9tIHJlLXBh cnRpdGlvbmluZyBhDQptZXNzYWdlIG9ubHkgaW4gdGhlIGNhc2Ugd2hlcmUgZW5kLXRvLWVuZCBz ZWN1cml0eSBvZiBDb0FQIG1lc3NhZ2UgaXMNCmFwcGxpZWQsIHdoaWNoIGluIGN1cnJlbnQgc29s dXRpb24gcHJvcG9zYWxzIGlzIGluZGljYXRlZCB3aXRoIHRoZQ0KcHJlc2VuY2Ugb2YgYSBjZXJ0 YWluIENvQVAgb3B0aW9uIFggKHdoaWNoIGUuZy4gY29udGFpbnMgdGhlIENPU0Ugb2JqZWN0KS4N ClRoaXMgd291bGQgaGF2ZSB0aGUgc2FtZSBiZW5lZml0cyBhcyB0aGUgcHJldmlvdXMgc29sdXRp b24sIGJ1dCByZXF1aXJlcw0KdGhlIGNvZGUgaW4gdGhlIHByb3h5IGltcGxlbWVudGluZyB0aGlz IGRyYWZ0IHRvIGJlIGF3YXJlIG9mIG9wdGlvbiBYLCBhbmQNCmhlbmNlIHRoYXQgZGVwZW5kZW5j eSBuZWVkcyB0byBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdC4gQW5kIG9wdGlvbiBYIGlzDQpu b3Qgc3RhbmRhcmRpemVkIHlldCwgc28gd291bGQgcmVxdWlyZSBpbnRyb2R1Y2luZyBhIHBsYWNl aG9sZGVyLg0KDQoNClRoZXJlIGFyZSBvdGhlciBhbHRlcm5hdGl2ZXMgYXMgd2VsbCBidXQgdGhp cyBlLW1haWwgaXMgYWxyZWFkeSB0b28gbG9uZy4NClRoZSBtYWluIHBvaW50IEkgd2FudGVkIHRv IG1ha2UgaXMgdGhhdCBnaXZlbiB0aGF0IHdlIG5vdyBoYXZlIGEgYmV0dGVyDQp1bmRlcnN0YW5k aW5nIG9mIGhvdyB0byBhY2hpZXZlIHNlY3VyaXR5IGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIg dGhyb3VnaA0KcHJveGllcyBjb21wYXJlZCB0byB3aGVuIFJGQzcyNTIgd2FzIHdyaXR0ZW4sIG15 IG9waW5vbiBpcyB0aGF0IHdlIHNob3VsZA0Kbm90IGlnbm9yZSB0aGVzZSBzZWN1cml0eSBpc3N1 ZXMgaW4gbmV3IHN0YW5kYXJkcy4NCg0KDQoNCkfDtnJhbg0KDQoNCg0KT24gMjAxNS0xMS0yMCAy MjozMiwgIlRoZSBJRVNHIiA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+ VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBDb25zdHJhaW5lZCBSRVNU ZnVsIEVudmlyb25tZW50cw0KPldHIChjb3JlKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRv Y3VtZW50Og0KPi0gJ0Jsb2NrLXdpc2UgdHJhbnNmZXJzIGluIENvQVAnDQo+ICA8ZHJhZnQtaWV0 Zi1jb3JlLWJsb2NrLTE4LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj5UaGUgSUVTRyBw bGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNp dHMNCj5maW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRp dmUgY29tbWVudHMgdG8gdGhlDQo+aWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTUt MTItMDQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZQ0KPnNlbnQgdG8gaWVzZ0BpZXRm Lm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCj5iZWdpbm5p bmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4NCj5B YnN0cmFjdA0KPg0KPg0KPiAgIENvQVAgaXMgYSBSRVNUZnVsIHRyYW5zZmVyIHByb3RvY29sIGZv ciBjb25zdHJhaW5lZCBub2RlcyBhbmQNCj4gICBuZXR3b3Jrcy4gIEJhc2ljIENvQVAgbWVzc2Fn ZXMgd29yayB3ZWxsIGZvciB0aGUgc21hbGwgcGF5bG9hZHMgd2UNCj4gICBleHBlY3QgZnJvbSB0 ZW1wZXJhdHVyZSBzZW5zb3JzLCBsaWdodCBzd2l0Y2hlcywgYW5kIHNpbWlsYXINCj4gICBidWls ZGluZy1hdXRvbWF0aW9uIGRldmljZXMuICBPY2Nhc2lvbmFsbHksIGhvd2V2ZXIsIGFwcGxpY2F0 aW9ucw0KPiAgIHdpbGwgbmVlZCB0byB0cmFuc2ZlciBsYXJnZXIgcGF5bG9hZHMgLS0gZm9yIGlu c3RhbmNlLCBmb3IgZmlybXdhcmUNCj4gICB1cGRhdGVzLiAgV2l0aCBIVFRQLCBUQ1AgZG9lcyB0 aGUgZ3J1bnQgd29yayBvZiBzbGljaW5nIGxhcmdlDQo+ICAgcGF5bG9hZHMgdXAgaW50byBtdWx0 aXBsZSBwYWNrZXRzIGFuZCBlbnN1cmluZyB0aGF0IHRoZXkgYWxsIGFycml2ZQ0KPiAgIGFuZCBh cmUgaGFuZGxlZCBpbiB0aGUgcmlnaHQgb3JkZXIuDQo+DQo+ICAgQ29BUCBpcyBiYXNlZCBvbiBk YXRhZ3JhbSB0cmFuc3BvcnRzIHN1Y2ggYXMgVURQIG9yIERUTFMsIHdoaWNoDQo+ICAgbGltaXRz IHRoZSBtYXhpbXVtIHNpemUgb2YgcmVzb3VyY2UgcmVwcmVzZW50YXRpb25zIHRoYXQgY2FuIGJl DQo+ICAgdHJhbnNmZXJyZWQgd2l0aG91dCB0b28gbXVjaCBmcmFnbWVudGF0aW9uLiAgQWx0aG91 Z2ggVURQIHN1cHBvcnRzDQo+ICAgbGFyZ2VyIHBheWxvYWRzIHRocm91Z2ggSVAgZnJhZ21lbnRh dGlvbiwgaXQgaXMgbGltaXRlZCB0byA2NCBLaUINCj4gICBhbmQsIG1vcmUgaW1wb3J0YW50bHks IGRvZXNuJ3QgcmVhbGx5IHdvcmsgd2VsbCBmb3IgY29uc3RyYWluZWQNCj4gICBhcHBsaWNhdGlv bnMgYW5kIG5ldHdvcmtzLg0KPg0KPiAgIEluc3RlYWQgb2YgcmVseWluZyBvbiBJUCBmcmFnbWVu dGF0aW9uLCB0aGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcw0KPiAgIGJhc2ljIENvQVAgd2l0aCBh IHBhaXIgb2YgIkJsb2NrIiBvcHRpb25zLCBmb3IgdHJhbnNmZXJyaW5nIG11bHRpcGxlDQo+ICAg YmxvY2tzIG9mIGluZm9ybWF0aW9uIGZyb20gYSByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBpbiBt dWx0aXBsZQ0KPiAgIHJlcXVlc3QtcmVzcG9uc2UgcGFpcnMuICBJbiBtYW55IGltcG9ydGFudCBj YXNlcywgdGhlIEJsb2NrIG9wdGlvbnMNCj4gICBlbmFibGUgYSBzZXJ2ZXIgdG8gYmUgdHJ1bHkg c3RhdGVsZXNzOiB0aGUgc2VydmVyIGNhbiBoYW5kbGUgZWFjaA0KPiAgIGJsb2NrIHRyYW5zZmVy IHNlcGFyYXRlbHksIHdpdGggbm8gbmVlZCBmb3IgYSBjb25uZWN0aW9uIHNldHVwIG9yDQo+ICAg b3RoZXIgc2VydmVyLXNpZGUgbWVtb3J5IG9mIHByZXZpb3VzIGJsb2NrIHRyYW5zZmVycy4NCj4N Cj4gICBJbiBzdW1tYXJ5LCB0aGUgQmxvY2sgb3B0aW9ucyBwcm92aWRlIGEgbWluaW1hbCB3YXkg dG8gdHJhbnNmZXINCj4gICBsYXJnZXIgcmVwcmVzZW50YXRpb25zIGluIGEgYmxvY2std2lzZSBm YXNoaW9uLg0KPg0KPg0KPg0KPg0KPlRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvcmUtYmxvY2svDQo+DQo+ SUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1ibG9jay9iYWxsb3QvDQo+DQo+DQo+Tm8gSVBS IGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0K Pg0KPg0KDQo= From nobody Thu Nov 26 00:08:56 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E45D1B3608; Thu, 26 Nov 2015 00:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WodIabZoA7fg; Thu, 26 Nov 2015 00:08:51 -0800 (PST) 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 A03E51B3607; Thu, 26 Nov 2015 00:08:50 -0800 (PST) Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 29CC541C08F; Thu, 26 Nov 2015 09:08:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter29-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eJhgIHvOkP4e; Thu, 26 Nov 2015 09:08:47 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B4C1E41C08D; Thu, 26 Nov 2015 09:08:37 +0100 (CET) Message-ID: <5656BE03.3090604@tzi.org> Date: Thu, 26 Nov 2015 09:08:35 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "core-chairs@ietf.org" , "ietf@ietf.org" , "core@ietf.org" , "barryleiba@gmail.com" , "draft-ietf-core-block@ietf.org" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 08:08:52 -0000 G枚ran Selander wrote: > we should > not ignore these security issues in new standards. Definitely, we shouldn't ignore these security issues when defining new standards. Now why is this a comment on the IETF last-call for an existing specification? It's not like Block was invented yesterday and people are still figuring out how to implement it. For years, it has actually been part of a number of specifications that were derived from the CoAP specifications. It isn't very likely that spending another year or two on finding out what specific mandates on proxies might possibly make life a bit easier for a new object security specification would have any influence on today's CoAP implementations. When you have found out what is needed, write what you need into that object security specification. Document the level of backwards compatibility achieved (hint: You may want to carefully define your objectives here). (And don't forget that you should be solving the problem for cross-protocol proxies as well.) Gr眉脽e, Carsten From nobody Thu Nov 26 00:43:48 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7D21B3728; Thu, 26 Nov 2015 00:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI33hIY5X1jG; Thu, 26 Nov 2015 00:43:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E401B3726; Thu, 26 Nov 2015 00:43:43 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-0c-5656c63d1d38 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.2B.05149.D36C6565; Thu, 26 Nov 2015 09:43:41 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 26 Nov 2015 09:43:21 +0100 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Carsten Bormann Thread-Topic: Last Call: (Block-wise transfers in CoAP) to Proposed Standard Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEAgAAAkICAABp4gA== Date: Thu, 26 Nov 2015 08:43:20 +0000 Message-ID: References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com> <5656BE03.3090604@tzi.org> In-Reply-To: <5656BE03.3090604@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <1530EF0D3BF7EC45A56C1628088A91F4@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyM2K7sa7tsbAwg7XXFC2+P7/GYnFkyl1W i20bL7BZ7Hu7ntmi8dA8RotnG+ezWDx73sLowO6xc9Zddo8lS34yedx+PZ/ZY9qizACWKC6b lNSczLLUIn27BK6MNWtmMxcc4K+49q+NrYGxh7+LkZNDQsBEov9UGzuELSZx4d56ti5GLg4h gcOMEvs/PmKHcBYzSvQufMAKUsUm4CLxoOERE4gtIqAkceHiGrAOZoE5TBI7G2+xgSSEBXIk Xnz7BFTEAVSUK7F8pjVEvZPE30+NjCA2i4CqxIL+WcwgNq+AhcTMpt2sEMu6GSXObXkAtoBT QF1iavtksAZGoPO+n1oDFmcWEJe49WQ+E8TZAhJL9pxnhrBFJV4+/gd2qKiAnsTK601sEHEl iRXbLzGC3MMsoCmxfpc+xBhriXONV9kgbEWJKd0P2SHuEZQ4OfMJywRGiVlIts1C6J6FpHsW ku5ZSLoXMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiM5YNbfhvsYHz53PEQowAHoxIP 74bSsDAh1sSy4srcQ4wSHMxKIrwx2UAh3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNIT S1KzU1MLUotgskwcnFINjLPPHNpm9uLP1SUnX/6WCw/YqfJr26Ps4LgDbLv//5jz8dic7ckb H5wW6pb5vluv2eyMhOCSv0ly1Z8lvc8IbFa8efV50jQHvdypPex6J533H/K1Xpq14uYMB7O7 oomppZUBRtM6s5+X84nHe3nbXmVb2tSUe/rvGp9flVWzKn6t+OFcdjUjPk6JpTgj0VCLuag4 EQCZ0vO74QIAAA== Archived-At: Cc: "core-chairs@ietf.org" , "ietf@ietf.org" , "core@ietf.org" , "barryleiba@gmail.com" , "draft-ietf-core-block@ietf.org" Subject: Re: [core] Last Call: (Block-wise transfers in CoAP) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 08:43:46 -0000 DQoNCk9uIDIwMTUtMTEtMjYgMDk6MDgsICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJvQHR6aS5vcmc+ IHdyb3RlOg0KDQo+R8O2cmFuIFNlbGFuZGVyIHdyb3RlOg0KPj4gd2Ugc2hvdWxkDQo+PiBub3Qg aWdub3JlIHRoZXNlIHNlY3VyaXR5IGlzc3VlcyBpbiBuZXcgc3RhbmRhcmRzLg0KPg0KPkRlZmlu aXRlbHksIHdlIHNob3VsZG4ndCBpZ25vcmUgdGhlc2Ugc2VjdXJpdHkgaXNzdWVzIHdoZW4gZGVm aW5pbmcgbmV3DQo+c3RhbmRhcmRzLg0KPg0KPk5vdyB3aHkgaXMgdGhpcyBhIGNvbW1lbnQgb24g dGhlIElFVEYgbGFzdC1jYWxsIGZvciBhbiBleGlzdGluZw0KPnNwZWNpZmljYXRpb24/IA0KDQpJ 4oCZbSBzb3JyeSBpZiB5b3UgZmluZCB0aGlzIGNvbW1lbnQgY29taW5nIGEgYml0IGxhdGUuIExl dCBtZSBleHBhbmQgb24gdGhlDQpoaXN0b3J5LiANCg0KQXMgbWVudGlvbmVkIHRoZSBvYmplY3Qg c2VjdXJpdHkgd29yayBoYXMgYmVlbiBnb2luZyBvbiBzaW5jZSBhIHllYXINCnN0YXJ0aW5nIHdp dGggQ29BUC4gV2hlbiB0dXJuaW5nIHRvIHRoZSBvdGhlciBkcmFmdHMgaW4gdGhlIENvQVAgc3Vp dGUsIHdlDQpjb3VsZG4ndCB1bmRlcnN0YW5kIGhvdyBibG9ja3dpc2Ugd29ya3Mgd2l0aCBwcm94 aWVzIGZyb20gdGhlIGRyYWZ0IGFuZA0KYXNrZWQgdGhlIHF1ZXN0aW9uIHRvIHRoZSBDT1JFIGxp c3QgKEp1bmUpLiBUaGUgb25seSBhbnN3ZXIgd2UgZ290IHdhcw0KYWN0dWFsbHkgd3JvbmcsIGlu IHRoZSBzZW5zZSB0aGF0IGl0IGdhdmUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGlzIGlzIG5vdA0K YSBwcm94eSBvcGVyYXRpb24gdGhhdCB3b3VsZCBiZSBvZiBhbnkgdXNlIC0gYW4gaW5kaWNhdGlv biB0aGF0ICBibG9ja3dpc2UNCnByb3h5IG9wZXJhdGlvbnMsIGFsdGhvdWdoIG5vdCBpbnZlbnRl ZCB5ZXN0ZXJkYXksIGhhcyBub3QgYmVlbiB3ZWxsDQp1bmRlcnN0b29kLg0KDQpJdCB3YXMgbm90 IHVudGlsIHRoZSBzb2NpYWwgZXZlbnQgaW4gUHJhZ3VlIChKdWx5KSB3aGVyZSB3ZSBsZWFybnQg KGluDQpwcml2YXRlIGNvbnZlcnNhdGlvbikgdGhhdCB0aGlzIGlzIG5vdCBhIGNvcm5lciBjYXNl LiBJbiB0aGUgbWFpbA0KZGlzY3Vzc2lvbiB0aGF0IGZvbGxvdyBvbiB0aGUgQ29SRSBsaXN0IEkg Zm9ybXVsYXRlIHRoaXMgcHJvYmxlbSBhcyBhDQpxdWVzdGlvbiB0byB5b3UgYnV0IEkgZG9u4oCZ dCBnZXQgYW55IGFuc3dlciAoU2VwdC4gMikuIEluIHRoZSBDT1JFIFdHIGYyZg0KbWVldGluZyBp biBZb2tvaGFtYSBJIHJhaXNlZCB0aGUgaXNzdWUgd2l0aCBibG9ja3dpc2UgYW5kIHByb3Bvc2Vk DQpzb2x1dGlvbiBpbiBteSBwcmVzZW50YXRpb24gKE5vdi4gNSksIGJ1dCB0aGVyZSBpcyBubyBj b21tZW50Lg0KDQpUaGF0IGlzIHdoeSB0aGlzIGlzIGEgY29tbWVudCBvbiB0aGUgSUVURiBsYXN0 LWNhbGwuDQoNCkfDtnJhbg0KDQoNCg== From nobody Thu Nov 26 19:22:45 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093501A8A16 for ; Thu, 26 Nov 2015 19:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sukoOsgfy8Dn for ; Thu, 26 Nov 2015 19:22:43 -0800 (PST) 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 0DC631A8A12 for ; Thu, 26 Nov 2015 19:22:43 -0800 (PST) Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 6960CC5A49; Fri, 27 Nov 2015 04:22:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rRuT-5SH45yW; Fri, 27 Nov 2015 04:22:40 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D2B90C5A4F; Fri, 27 Nov 2015 04:22:39 +0100 (CET) Message-ID: <5657CC7E.4040008@tzi.org> Date: Fri, 27 Nov 2015 04:22:38 +0100 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] BERT (Block protocol Extension for Reliable Transport) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Nov 2015 03:22:45 -0000 In Prague and Yokohama, we had several discussions about the CoAP over TCP mapping, its larger message size limit (now 64 KiB, compared to the 1152 bytes we came up with for UDP or DTLS/UDP), and ideas about extending the Block protocol to make use of that capability. G枚ran has reminded me of the Block protocol today :-), so I quickly wrote up what I think is a minimal extension to Block for this: BERT (Block protocol Extension for Reliable Transport) https://tools.ietf.org/html/draft-bormann-core-block-bert-00 My questions to the WG: -- do we (CoRE WG) want to do this? -- does it work for you and your implementation? -- is is already simple enough*)? -- any opportunities this proposal misses? Gr眉脽e, Carsten *) from an implementation point of view, not with respect to exposition -- but I'm happy to take comments on the latter as well. Title: Block-wise transfers in CoAP: Extension for Reliable Transport (BERT) Abstract: CoAP (RFC7252) is a RESTful transfer protocol for constrained nodes and networks, originally using UDP or DTLS over UDP as its transport. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. CoAP's Block protocol (draft-ietf-core-block) allows transferring larger payloads over limited-size datagrams -- for instance, for firmware updates. CoAP over TCP and TLS (draft-ietf-core-tcp-tls) enables the use of extended, but not unlimited, size messages. The present specification, Block-wise transfers in CoAP: Extension for Reliable Transport (BERT), extends the block protocol in a simple way to be able to make use of these larger messages over a reliable transport. From m.kwiatkowski@avsystem.com Fri Nov 27 06:49:07 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8B1B34B3 for ; Fri, 27 Nov 2015 06:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.084 X-Spam-Level: *** X-Spam-Status: No, score=3.084 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPi1TCiZWe8O for ; Fri, 27 Nov 2015 06:49:05 -0800 (PST) Received: from v112405.home.net.pl (v112405.home.net.pl [188.128.134.137]) by ietfa.amsl.com (Postfix) with SMTP id 15DB51B34B2 for ; Fri, 27 Nov 2015 06:49:04 -0800 (PST) Received: from 81-18-220-1.static.chello.pl (81.18.220.1) (HELO [10.10.53.53]) by avsystem.home.pl (188.128.134.137) with SMTP (IdeaSmtpServer v0.80) id 5f5a71e794fc7b1e; Fri, 27 Nov 2015 15:49:03 +0100 From: Mateusz Kwiatkowski To: core@ietf.org Message-ID: <56586D5F.50407@avsystem.com> Date: Fri, 27 Nov 2015 15:49:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [core] Block1 vs. other options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Nov 2015 14:50:39 -0000 Hello, First of all, this is my first post to any of the IETF mailing lists, so please correct me if I'm doing anything against the common etiquette. While studying and working on an implementation of the Block-wise transfer in CoAP, I came across an apparent ambiguity of the current draft spec. Specifically - how should other CoAP options (not related to the BLOCK document) be treated when performing a block-wise request (utilizing Block1)? Should they be repeated on every message? Or may they be omitted on all requests save from some specific one - first or last perhaps? Should the server e.g. validate whether Uri-Path values match between subsequent blocks? None of these questions seems to be addressed by the document. This issue is especially significant for implementations that attempt to abstract the block-wise nature of the message exchange away from the actual business logic. This is what e.g. Eclipse Californium does, and it actually seems to ignore any non-BLOCK-related options from all but the last message in block sequence. Such implementation apparently cannot fulfill the requirement from RFC 7252 section 5.4.1, which explicitly states that unrecognized options of class "critical" MUST cause the message to be rejected. Of course this is not itself a defect of the protocol, but a more specific requirement in the BLOCK spec would help to avoid such arbitrary decisions. By my personal judgment, not repeating the options in every message would be the way to go - saving bandwidth, and making it much easier to fulfill the above-mentioned requirement while using abstractions like the one in Californium. It would then, however, remain an open problem, which block to use as "option source" - first or last? Requiring the client to repeat the options, and the server to verify their consistency (like with Content-Format), would offer more robustness, but waste bandwidth and complicate server implementations. In any case, I believe that this is an ambiguity that should be addressed. Unless I'm misunderstanding something and answers to my questions can be inferred from some other parts of the spec. Best regards, Mateusz From nobody Fri Nov 27 08:35:20 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6D1B362A for ; Fri, 27 Nov 2015 08:35:19 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwmfO8h0jEF2 for ; Fri, 27 Nov 2015 08:35:16 -0800 (PST) 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 A6D031B3627 for ; Fri, 27 Nov 2015 08:35:16 -0800 (PST) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 7CF49A80DF; Fri, 27 Nov 2015 17:35:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id CBEORdtY-pfI; Fri, 27 Nov 2015 17:35:12 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 5AA4DA80D9; Fri, 27 Nov 2015 17:35:12 +0100 (CET) Message-ID: <5658863E.5070004@tzi.org> Date: Fri, 27 Nov 2015 17:35:10 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Mateusz Kwiatkowski References: <56586D5F.50407@avsystem.com> In-Reply-To: <56586D5F.50407@avsystem.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] Block1 vs. other options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Nov 2015 16:35:19 -0000 Hi Mateusz, questions like yours are indeed most welcome here. Let me try to give a quick answer now; we can maybe refine that later. > Specifically - how should other CoAP options (not related to the BLOCK > document) be treated when performing a block-wise request (utilizing > Block1)? Should they be repeated on every message? Yes. > Or may they be > omitted on all requests save from some specific one - first or last > perhaps? No. > Should the server e.g. validate whether Uri-Path values match > between subsequent blocks? Actually, if a server receives two requests with different Uri-Path values, they are unrelated, so there is no need (actually: it would be wrong) to validate a match. (What will happen if, say, the client simply leaves out the Uri-Path options on what it things is the second request in sequence? A 4.08, because the server does not have the previous blocks needed to perform a PUT or POST to / -- the URI implied by Uri-Path options absent.) > None of these questions seems to be addressed > by the document. We do discuss the situation where the Content-Format options do not match (last paragraph of section 2.3). 2.4 is quite clear in saying: 2.4. Using the Block2 Option When a request is answered with a response carrying a Block2 Option with the M bit set, the requester may retrieve additional blocks of the resource representation by sending further requests with the same options as the initial request and a Block2 Option giving the block number and block size desired. ... "with the same options as the initial request". You are right that the text is never spelling out the same as explicitly for Block1, however, e.g. the text The Block1 option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations to the same resource. Starting a new block-wise sequence of requests to the same resource (before an old sequence from the same endpoint was finished) simply overwrites the context the server may still be keeping. (This is probably exactly what one wants in this case - the client may simply have restarted and lost its knowledge of the previous sequence.) does not really make any sense if Block1 were meant to have completely different semantics. > This issue is especially significant for implementations that attempt to > abstract the block-wise nature of the message exchange away from the > actual business logic. This is what e.g. Eclipse Californium does, and > it actually seems to ignore any non-BLOCK-related options from all but > the last message in block sequence. Such implementation apparently > cannot fulfill the requirement from RFC 7252 section 5.4.1, which > explicitly states that unrecognized options of class "critical" MUST > cause the message to be rejected. Time to file a bug, I'd say. > Of course this is not itself a defect of the protocol, but a more > specific requirement in the BLOCK spec would help to avoid such > arbitrary decisions. By my personal judgment, not repeating the options > in every message would be the way to go - saving bandwidth, and making > it much easier to fulfill the above-mentioned requirement while using > abstractions like the one in Californium. It would then, however, remain > an open problem, which block to use as "option source" - first or last? > Requiring the client to repeat the options, and the server to verify > their consistency (like with Content-Format), would offer more > robustness, but waste bandwidth and complicate server implementations. Well, first of all a server needs the Cache Key (Uri-Path etc.) in order to find which of the many Block1 requests you may be getting at a particular point in time from the same endpoint actually refers to the same resource -- there is of course nothing wrong with concurrent Block1 sequences being performed to different resources at the same time. In many cases, the server is free to implement Block1 atomically or in a stateless fashion -- if the client is not supplying the options with every request, that is not possible. (Content-Format is somewhat special because it is part of the resource state.) > In any case, I believe that this is an ambiguity that should be > addressed. Unless I'm misunderstanding something and answers to my > questions can be inferred from some other parts of the spec. Do you have any specific places in mind where an editorial change should be made? Now is still a very good time to make these. Gr眉脽e, Carsten From nobody Mon Nov 30 08:34:46 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5991ACF59; Mon, 30 Nov 2015 08:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC767HFBoAwo; Mon, 30 Nov 2015 08:34:43 -0800 (PST) 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 1E0311ACF16; Mon, 30 Nov 2015 08:34:38 -0800 (PST) Received: from localhost ([::1]:50047 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1a3RPS-00062Q-AR; Mon, 30 Nov 2015 08:34:38 -0800 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: Mon, 30 Nov 2015 16:34:38 -0000 X-URL: https://tools.ietf.org/core/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/core/trac/ticket/387 Message-ID: <065.c5694a46c59ee3c07f861a916ef7b781@trac.tools.ietf.org> X-Trac-Ticket-ID: 387 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: <20151130163442.1E0311ACF16@ietfa.amsl.com> Resent-Date: Mon, 30 Nov 2015 08:34:38 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Archived-At: Cc: core@ietf.org Subject: [core] #387 (coap-tcp-tls): Should ALPN always be required? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 30 Nov 2015 16:34:45 -0000 #387: Should ALPN always be required? Section 6.2 of says: o When CoAP is exchanged over TLS port 443 then the "TLS Application Layer Protocol Negotiation Extension" [RFC7301] MUST be used to allow demultiplexing at the server-side unless out-of-band information ensures that the client only interacts with a server that is able to demultiplex CoAP messages over port 443. This would, for example, be true for many IoT deployments where clients are pre-configured to only ever talk with specific servers. QUESTION: Shouldn't we simply always require ALPN? The protocol should not be defined in such a way that it depends on some undefined pre- configuration mechanism. --cabo -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-core-coap- Hannes.Tschofenig@gmx.net | tcp-tls@ietf.org Type: other technical | Status: new Priority: major | Milestone: Component: coap-tcp-tls | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: core From nobody Mon Nov 30 08:48:15 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3744A1AD0AF for ; Mon, 30 Nov 2015 08:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKne_vYf43Qd for ; Mon, 30 Nov 2015 08:48:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659E41AD0A9 for ; Mon, 30 Nov 2015 08:48:13 -0800 (PST) Received: from [192.168.10.143] ([80.92.121.34]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MN604-1Zwoqp0Qe0-006c0E for ; Mon, 30 Nov 2015 17:48:11 +0100 To: "core@ietf.org WG" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <565C7DC8.6010704@gmx.net> Date: Mon, 30 Nov 2015 17:48:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I50hmhl5qImlN9hVTQoWFWJNDwAPk0EVf" X-Provags-ID: V03:K0:MV7SrNurjwWJ9EWVZnqOqRHMzkVFC2FMIb/HN5r2lTXURTqH770 mFsHVq4RmDPwx1omIXv5eorvJeQN0DZJHmHBuw7U9OKjyq6Fj3yqhebP/z788zDZauxEgJc Q7/h/zKGtC9A09oV1dHzlQD8WxCMpD/19I0U4ygpMHGOyqA90wU7R1eTcRrjjv/oucQtN4t 4jhFyw67gJ35M9/4g7akg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KfAXFzV08HM=:mfUNQQZA98AyS45PFYV9oy IesyE/Z+MrQMUZRzDM3LE01EW43GJnnmq2UNbmoGtlbIa5XVNoA4hp4LmorEVTHMu+HuOrXOT vouATZuyPbGxP3CwryW9cPzAExRrRSIjLHxuDaEdn9qoKjek57E/I8VyQQeCLuORXhqLGEaRq zxptmXvSdtRFNgumrOmt7CelTtO3vTZmVIZLN1KVG2sq2UuQQa+IlyF1KtdOsaS9N9pqQJ5tN K5Do1tGu2h90XN5jZoNvU/s6u59qWJ42wcxT3bYBeje7YUqNFZPpvBB/EJxAZt7qLqhOaA3Tv E48f9tYYHmaMym5xKrAPV41Ec997skRw/gXebAorxsPsCdsE29ehMmPlvZ+UJ/Q+c+Sln4SSY CUdZiHgY2FMFda38RWWMcr2i3ZUX7nwnlYR1QT9WWeNMQ//IeozurVF6dIr3teDz8k+ZpFpiH lxvSlw+tfV7vQeZciHOp0gY4uh3sbn4BkdGEgWIfpWLBnMzWXmBLV9aO0QxDMEexut4gZ4IHG DMEeAh1yB3k9MK6IL79JWuymC3k2hoo+JLOQI2wPC+aN/TU0HZ0cL7NucojbBSbcwLgjN+IYu VVWb+X7Ndx74FkyrtsxgBZts8t8cLpRQzsduF0uSJpkGqllp8evycb+7m/9LtVqTwvYsHxWe+ LHmEGg7E5cTeRaET+fUtlvrUlT0Be7xjR2hDL0i7AXbI/A4zdo2up+J7UfLTg2gvk5MKwV6Ve sa1Znd07hav+VX5giLfZ8ZFZTcy2W6Zoah/kGQQysB+HuWIGTWGgzW5stX8= Archived-At: Subject: [core] Open Issues for CoAP over TCP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:48:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I50hmhl5qImlN9hVTQoWFWJNDwAPk0EVf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, recently the CoAP over TCP draft was submitted as a WG item. To progress the work I started to add the first open issue t the issue tracker. Feel free to add further issues that require discussion. Here is a link to the issue tracker: http://trac.tools.ietf.org/wg/core/trac/query?component=3Dcoap-tcp-tls Ciao Hannes --I50hmhl5qImlN9hVTQoWFWJNDwAPk0EVf 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 iQEcBAEBCgAGBQJWXH3JAAoJEGhJURNOOiAtyA4H+gLDg58WboAVjyzgrSE7S3QA SRRb7Aq78gZhWq4a0hb2UERAGtIXUFbueFFeFI3yXaVMpKtgmbih7kl95IpLzCfB vC3V5annOXrKhOAcODdvwGo8rPi1g+0GBS2kaG1RvcQRvb5cV/FQsCHhMq0Wp9cb /QK8TTP67b1NWT8Ofj4oO1BnzcnGozsqDGhOJ5X1dCdHKBk9/5GUPFgEQu6ydZ0A odWN/XY+nEkRIOjxEMjD2I1V6YAgbzHzROG20YsgOg1YA+m5D3+iVx8An38ZrsCh ++QU6VbmQkIu4Npf7pslOGEDVXZBZwQTcalxoHaLupRiPbp+QcrpNfBawTaxF5A= =ruV5 -----END PGP SIGNATURE----- --I50hmhl5qImlN9hVTQoWFWJNDwAPk0EVf-- From nobody Mon Nov 30 20:33:25 2015 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2341A212D for ; Mon, 30 Nov 2015 20:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azh7JfyH2zUf for ; Mon, 30 Nov 2015 20:33:21 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9C1A2119 for ; Mon, 30 Nov 2015 20:33:20 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 50E7A19F4E0 for ; Tue, 1 Dec 2015 12:33:18 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.241.89]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 9FA0519F4C1; Tue, 1 Dec 2015 12:33:17 +0800 (HKT) Message-ID: From: "weigengyu" To: "Hannes Tschofenig" References: <565C7DC8.6010704@gmx.net> In-Reply-To: <565C7DC8.6010704@gmx.net> Date: Tue, 1 Dec 2015 12:33:22 +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] Open Issues for CoAP over TCP draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 Dec 2015 04:33:24 -0000 Hi, I would like to put some questions: 1. Whether to consider the inter-operations between CoAP over TCP and CoAP over UPD in this draft. Or this draft just concerns the CoAP over TCP only. My suggestion is to consider the inter-operations. 2. Is a CoAP semantics End-to-end or hop-by-hop. The CoAP semantics means both CoAP request/response layer and CoAP message layer. My suggestion is to handle in End-to-end. 3. Is it a right approach to handle the CoAP semantics, that is CoAP request/response semantics is handled in End-to-end and the CoAP is handled in hop-by-hop. My suggestion is both CoAP request/response and message layer are handled in End-to-end. Regards, > Hi all, > recently the CoAP over TCP draft was submitted as a WG item. To progress > the work I started to add the first open issue t the issue tracker. > Feel free to add further issues that require discussion. > Here is a link to the issue tracker: > http://trac.tools.ietf.org/wg/core/trac/query?component=coap-tcp-tls > Ciao > Hannes Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----鍘熷閭欢----- From: Hannes Tschofenig Sent: Tuesday, December 01, 2015 12:48 AM To: core@ietf.org WG Subject: [core] Open Issues for CoAP over TCP draft _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core